OAuth2 JWTプロファイルは、承認付与とクライアント認証の両方としてJWTを使用する可能性を導入します。
JWTクライアント認証機能は、特定の付与タイプに依存せず、任意の付与タイプ、およびクライアント資格情報の付与で使用できます。
ただし、JWT付与タイプを使用することは、構文がわずかに異なることを除いて、JWTクライアント認証でクライアント資格情報付与を使用することとまったく同じように見えます。
どちらの場合も、クライアントはトークンエンドポイントに接続してアクセストークンを取得します。
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=[JWT]
vs
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=[JWT]
Josh Cによるすばらしい答えについては、少し異なる見方があります。クライアント認証と付与資格情報の両方をJWTとして表現できますが、その背後にあるセマンティクスは異なります。
関心の分離についてです。クライアントは、クライアントを識別する資格情報を使用して認証します。つまり、クライアントはいわゆるですが、クライアントsubjectに発行された助成金を使用します。つまり、クライアントはいわゆるaudienceです。または、ドラフト仕様のバージョン12（https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12）にあるように：
JWTには、JWTのサブジェクトであるプリンシパルを識別する「サブ」（サブジェクト）クレームが含まれている必要があります。2つのケースを区別する必要があります。
A.承認付与の場合、サブジェクトは通常、アクセストークンが要求されている承認済みアクセサー（つまり、リソース所有者または承認済みデリゲート）を識別しますが、場合によっては、匿名を示す仮名識別子またはその他の値である可能性があります。ユーザー。
B.クライアント認証の場合、サブジェクトはOAuthクライアントの「client_id」でなければなりません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加