OIDCを使用して各APIリクエストで送信される情報

Question

OIDC（OpenID Connect）を使用して保護するAPIバックエンドを作成しています。私はドキュメントを読んできましたが、それぞれのAPI要求にどのようなプロセスが適用されるのか混乱しています。 Open ID Connectのコードフローは次のように表示されます。 1回限りの処理として、うまくいきます。私のバックエンドAPIは、HTTPヘッダーに認証コードを見て、IDトークンを取得する要求を認証サーバーに送信します。これによりOKが検証されると、要求されたデータがAPIレスポンスに返されます。

しかし、同じユーザーがこのAPIに対する多くのリクエストを行っていると仮定すると、その後のリクエストはどうなりますか？この仕組みで何らかのセッションが作成されていますか？同じ認証コードを引き続き受け取りますか？これらのバックチャネル要求を認可サーバーに送信し続ける必要がありますか？

また、JWT IDトークンをクッキーとして出力する必要がありますか？このようにして、私は、サーバー側のセッションやそれ以上のラウンドトリップを必要とせずに、今後のリクエストに自己完結型のIDトークンを戻すことができます。

Answer 1

通常、OpenID Connectではなく、（純粋な）APIをOAuth 2.0で保護します。あなたのAPIにアクセスするクライアントは、OAuth 2.0アクセストークンを取得する必要があります。そうするためには、OpenID Connectを使用してそのトークンを取得することがあります。これはAPIから独立しており、アクセストークンのみが表示されます。 API（またはOAuth 2.0用語のResource Server）は、図には表示されません。

Answer 2

私は、ドキュメントを読んでいるが、私はまだ少しは、それはOpenIDの接続プロトコルに従わなければならないAPIはなく、一人ひとりのAPIリクエスト

に適用されるものを プロセス混乱しています。それはそれを行うべきクライアントです。

私のバックエンドAPIは、HTTPヘッダーに認証コードを表示し、 は、IDトークンを取得するために認証サーバーに要求を送信します。 これがOKの場合、要求されたデータはAPI レスポンスに返されます。

承認コードは、APIエンドポイントではなくクライアントアプリケーションで使用する必要があります。また、認証コードを他のエンティティに公開してはなりません。

OpenID Connectで送信されたIDトークンを使用して、クライアントアプリケーションからエンドユーザーを認証する必要があります。 APIにアクセスするには、アクセストークンを使用する必要があります。

APIエンドポイントで何をすればよいですか？

私はこれがあなたが苦労するところだと思います。クライアントアプリケーションは、APIエンドポイントにアクセスするために有効なアクセストークンを送信する必要があります。 APIエンドポイントから、OAuth 2.0イントロスペクションエンドポイントを使用してトークンを検証できます。

RFC7662 - OAuth 2.0 Token Introspection

この仕様はOAuth 2.0の によってそれらに提示された与えられたトークンを メタデータのセットを決定するために、認証サーバを照会する 保護されたリソースを許可するプロトコルを定義クライアント。

OpenID Connectは、OAuth 2.0の上に構築されています。つまり、イントロスペクションエンドポイントを含むOAuth 2.0で定義されたものを使用できます。このエンドポイントを使用して、アクセストークンの有効性を確認します。

エンドユーザーの詳細をお望みの場合はどうなりますか？

OpenIDの接続は、ユーザ情報エンドポイント

User info endpoint

を規定のUserInfoエンドポイントは、認証されたエンドユーザーに関するクレームを返しOAuth 2.0の保護されたリソースです。エンドユーザに関する要求されたクレームを取得するために、クライアントは、OpenID Connect認証で取得したアクセストークンを使用してUserInfoエンドポイントに要求を行います。これらのクレームは通常、クレームの名前と値のペアの集合を含むJSONオブジェクトで表されます。

また、アクセストークンを使用してこのエンドポイントからユーザー情報を取得します。応答により、このトークンが発行されたエンドユーザを知ることができます。

特定のAPI要件に応じて、トークンイントロスペクションを実行するか、ユーザー情報エンドポイントからユーザー情報を取得できます。これが完了すると、セッションを認証して認証することができます。使用可能なすべての情報が必要な場合は、両方のエンドポイントを使用することもできます。

また、（セッションの代わりに）APIはアクセストークンキャッシュを維持できます。これにより、すべてのAPI呼び出しごとにトークンを検証する必要性がなくなります。しかし、トークンには有効期限があることに注意してください。このソリューションを選択する場合は、トークンの期限切れについて考慮する必要があります。

p.s - OpenIDの接続とOAuth 2.0の面では、リソースサーバ

対クライアントは、クライアントは、単純なWebページ、デスクトップアプリケーション可能性があり、さらには、サーバホストされるアプリケーションである可能性があります。

クライアント リソースの所有者に代わって、その権限を持つ保護されたリソースの要求を行うアプリケーション。 「クライアント」という用語は に特定の実装特性（例えば、アプリケーションがサーバ、デスクトップ、またはその他のデバイスで実行するかどうかを問わず、 ）を暗示するものではありません。 デバイス

トークンの取得と使用は、クライアントアプリケーションの義務です。一方

、リソースサーバは保護されたリソース、

リソースサーバ を受け入れ、アクセストークンを使用して保護されたリソース要求に対応できる保護されたリソースを、ホストしているサーバーが含まれています。

リソースサーバーは、トークンにアクセスするためのリソースを交換します。同じシナリオを基本認証に一致させると、アクセスヘッダーは認証ヘッダーで送信されたユーザー名/パスワードを置き換えます。