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]
対
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]
おそらく非常に少ない。クライアントの識別方法と認証付与の要求方法はOAuthの2つの異なる概念であるため、質問ではこれらの概念を個別に扱います。
仕様は、分離が単なる設計上の決定であり、政策立案者にどのシナリオが彼らにとって価値があるかを見つけることを遅らせることを示唆しているようです:
クライアント認証にセキュリティトークンを使用することは、認可トークンとしてセキュリティトークンを使用することとは直交し、分離できます。これらは、組み合わせて使用することも個別に使用することもできます。 JWTを使用したクライアント認証は、クライアントがトークンエンドポイントに対して認証するための代替方法にすぎず、完全で意味のあるプロトコル要求を形成するために、何らかの付与タイプと組み合わせて使用する必要があります。 JWT許可付与は、クライアントの認証または識別の有無にかかわらず使用できます。サポートされているタイプのクライアント認証と同様に、JWT許可付与とともにクライアント認証が必要かどうかは、許可サーバーの裁量でのポリシー決定です。
具体的な可能性の1つ:分離により、承認サーバーがクライアントタイプに沿って異なるポリシーを設定できるようになります。たとえば、パブリッククライアント(モバイルアプリなど)の場合、サーバーはクライアント資格情報付与タイプを受け入れてはなりません。代わりに、サーバーはパブリッククライアントのJWT付与タイプを受け入れ、より低い特権のトークンを発行できます。
それ以外は、クライアントとサーバーが自由に自由に回転できるように設計されていると思います-必要に応じて、この部分を移行しながら既存のハンドシェイクのこの部分を維持します。