2

私は次のことを達成しようとしているユースケースに取り組んでいます:

  1. OpenID Connect プロトコルを使用します。仕様はこちら: ( http://openid.net/specs/openid-connect-core-1_0.html )

  2. /oauth2/access_token エンドポイントへの呼び出しを発行します。

    を。リソース認証の場合: 使用grant_type=urn:ietf:params:oauth:grant-type:jwt-bearerThis is as per the spec ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer-12 )

    b. クライアント認証の場合:client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerこれもまた、上記の #a にリストされているのと同じ仕様に従って使用します。

私の質問は：

Open ID Connect の仕様では、「認証コード」と「暗黙の」付与シナリオについてのみ説明していることを知っています。ただし、Open ID 仕様を JWT Bearer 仕様と組み合わせて使用​​する予定です。つまり、JWT ベアラー グラント タイプを介して OAuth2.0 トークン API (/access_token) への 1 回の呼び出しで認証と承認の情報を送信し、代わりにアクセス トークンと id_token を受け取ります。これは可能ですか、それとも Open ID Connect 仕様に違反することになりますか?

4

2 に答える 2

3

これは循環参照になるため、仕様では定義されていません。OpenID Connect の主な機能は、クライアントにid_token配信される を通じてクライアントに対してユーザーを認証することです。はid_token、ユーザーと認証のプロパティを記述する JWT です。クライアントは、ユーザーからいわゆるグラントを受け取り、id_tokenそのユーザーの情報を取得します。

許可がすでに (必然的に) ユーザーと認証イベントに結び付けられている JWT である場合、基本的に同じことを説明する別のものを取得する必要はありません (基本的にそれが Implicit 許可によって達成されます)。許可がユーザー認証に関連付けられていない場合、id_tokenOpenID Connect のセマンティクスに違反するため、許可を使用して を取得することはできません。

したがって、JWT ベアラー グラント タイプは、OAuth 2.0 (委任された承認) シナリオでは意味がありますが、OpenID Connect (ユーザー認証) シナリオでは意味がありません。

もちろん、JWT (ユーザーおよび/またはユーザー認証とは無関係) をクライアント認証の目的で使用することは可能ですが、許可としてではなく、認証コード許可のクライアント シークレットの代替として使用されます。

于 2015-08-04T20:44:45.563 に答える