SPAおよびRESTful APIのOIDCフロー

Question

Single-Page App（SPA）とRESTful APIを構築しています。 APIにはセキュリティが必要です。特定のユーザーは特定のエンドポイントへの呼び出ししか行えません。 OpenId Connectプロトコルを使用してユーザーに認証させる外部IDプロバイダー（IdP（Okta））があります。 RESTful APIへのSPAの認証と承認の正しい手順を明確にしようとしています。私が見てきた2つのフローは、承認コードフローと暗黙フローです。

Implicit flowを使用する場合、手順は次のようになります。

ユーザーがSPAにアクセスすると、ユーザーはIdPにリダイレクトされてサインインします。
ユーザーがサインインした後、IdPはアクセストークンとIDトークンを使用してユーザーをSPAに返します。
（これは私がよくわからない手順です）SPAがRESTful APIにリクエストを行うたびに、リクエストとともにアクセストークンとIDトークンを渡します。RESTfulAPIはそれを検証し、ユーザーがアクセスする権限を持っていることを確認します特定のエンドポイント。そうであれば結果を返し、そうでなければユーザーは無許可です。

Authorization Code flowを使用する場合、手順は次のようになります。

上記のステップ1と同じです。
ユーザーがサインインした後、IdPは認証コードとともにSPAにユーザーを返します。
（繰り返しますが、よくわからない手順は正しいです）SPAがRESTful APIにリクエストを行うたびに、リクエストとともに認証コードを渡し、RESTful APIは（クライアントシークレットとともに）IdPと交換します。アクセストークンとIDトークンの場合。これらを使用して、ユーザーが特定のエンドポイントにアクセスできるかどうかを確認します。それが結果を返す場合、それ以外の場合は不正です。

このシナリオで使用するのは暗黙のフローですが、手順は正しいですか？特にステップ3では、すべてのリクエストで2つのトークンを送信することは正しくないようです。しかし、ユーザーを検証して決定するには、両方のトークンが必要だと思います。感謝します！

Moshe Katz · Answer

暗黙的フローとAuthCodeフローの違いは次のとおりです。

暗黙的なフロー

注：2019年4月現在、Oauthワーキンググループ推奨されなくなりましたほとんどの場合、暗黙的なフローの使用があるため、より良い、より安全な方法同じことを達成します。

ユーザーがSPAに移動すると、ユーザーはIdPにリダイレクトされてサインインします。
ユーザーがサインインします（必要に応じてアプリケーションを承認します）。
IdPは、アクセストークンとIDトークンを使用してユーザーをSPAに戻します。
SPAのJavaScriptコードは、アクセストークンとIDトークンをブラウザーのlocalStorageに保存し、アクセストークンをREST APIに送信しますリクエストごとにサーバー（通常はAuthorization: Bearer <access token>ヘッダーとして）。
必要に応じて、REST APIサーバーはIdPと通信してアクセストークンの有効性をチェックします（多くの場合、IdPでトークンに署名し、その署名で十分であることを確認します。必要。）

承認コードの流れ

ユーザーがSPAに移動すると、ユーザーはIdPにリダイレクトされてサインインします。
ユーザーがサインインします（必要に応じてアプリケーションを承認します）。
IdPは認証コードとともにユーザーをSPAに戻します。
SPAのJavaScriptコードは、承認コードをREST APIサーバー上のloginエンドポイントに送信します。
REST APIサーバーは、承認コードを含むIdPサーバーにリクエストを送信します（通常は、REST APIサーバーがIdPサーバー）。
IdPは認証コードを検証し、アクセストークンとIDトークンをREST APIサーバーに送信します。
REST APIサーバーは、アクセストークンとIDトークンをメモリに保存し、独自のセッショントークンをSPAに送り返します。
SPAがREST APIサーバーに対して行うすべての要求に対して、REST APIサーバーが付与したセッショントークンが含まれます。REST APIサーバーは別のサーバーにリソースをリクエストする必要があります。それは、格納されているアクセストークンを使用してそのリクエストを行います。

ここから、AuthCodeフローはImplicitフローよりもはるかに複雑ですが、アクセストークンがユーザーのコントロールに格納されないという利点があります。

ただし、この場合のトークンの保存の主な目的は、独自の認証ではなく、REST APIサーバーがGoogle、Facebookなどの他のサービスと通信する必要がある場合です。 Twitterなど.

自分のログインにOpenID Connectのみを使用している場合REST APIサーバー、ただしサーバー自体が認証情報を使用する必要がないため、暗黙的に実装フローは大幅に簡単になり、AuthCodeフローを実装しても実際には何も得られません。