For Authlete 2.x documentation, see 2.x version.
概要
RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants の Section 2.1. Using JWTs as Authorization Grants では、RFC 6749 で定義されている OAuth 2.0 標準フロー群とは異なる、アクセストークン発行のためのフローを定義しています。我々はそれを JWT 認可グラントフローと呼んでいます。 そのフローでは、JWT (RFC 7519) が認可グラントとして使用されます。認可グラントは、その保持者がアクセストークンを取得する認可を得ていることを示すものです。認可グラントとしての JWT は、認可コードフロー (RFC 6749 Section 4.1) の認可コードと同じ概念です。 アクセストークン要求者は、トークンエンドポイント (RFC 6749 Section 3.2) で JWT を提示することによりアクセストークンを取得できます。次の図はそのフローを示しています。
仕様
JWT の出所
**認可グラントとしての JWT が誰によってどのように生成されるかに関する詳細を RFC 7523 では定義していません。**従って、JWT の署名を検証するのに用いる鍵の入手方法が仕様では定義されていません。そのため、署名検証用鍵を特定するのに必要な独自規則をそれぞれの運用が定義しなければなりません。 例えば、システムは 「JWT はhttps://example.com が発行した ID トークンでなければならない」 という規則を定めるかもしれません。JWT が ID トークンであれば、認可サーバーの実装は標準的な仕組み (つまりディスカバリーエンドポイントと jwks_uri サーバーメタデータ) を使って署名検証用鍵を見つけることができます。他のシステムは、OpenID Connect Federation 1.0 のエンティティーステートメントと同じように、JWT 自身に署名検証用鍵を埋め込むことを選択するかもしれません。
いずれにしても、RFC 7523 を採用する際は、同仕様を補完するための追加規則を定義しなければなりません。
トークンリクエスト
グラントタイプ
JWT 認可グラントフローと他のフローを区別するため、新しいグラントタイプurn:ietf:params:oauth:grant-type:jwt-bearer が仕様で定義されています。この値はトークンリクエストの grant_type リクエストパラメーターの値として使用されます。
クライアントの特定と認証
仕様は、トークンエンドポイントにおける**クライアント認証を要求しておらず、さらにはクライアントの特定**すら要求していません。仕様は次のように述べています。JWT authorization grants may be used with or without client authentication or identification. JWT 認可グラントの使用に際し、クライアント認証やクライアント特定が伴いうる。技術的には 『クライアント認証が伴いうる』 とは、クライアントアプリケーションのクライアントタイプ (RFC 6749 Section 2.1) がパブリックなのかコンフィデンシャルなのかについて仕様は気にしないということを意味しています。また 『クライアント未特定』 とは、トークンリクエストがクライアントを特定するための情報を含んでいないことを意味します (例えば
client_id リクエストパラメーターの欠如など)。
スコープ
OAuth 2.0 標準フロー群でも可能なように、JWT 認可グラントフローのトークンリクエストにおいても、要求するスコープ群をscope リクエストパラメーターで指定することができます。
アサーション
認可グラントとして用いる JWT はassertion リクエストパラメーターで指定されます。このリクエストパラメーターは、RFC 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants の Section 4.1. Using Assertions as Authorization Grants で定義されています。
次の表は、JWT クレーム群の要否を要約したものです。クレーム群に対する詳細な要求事項は RFC 7523 の Section 3 で説明されています。
リクエストの例
次のものは、RFC 7523 の Section 2.1 に掲載されている例です。トークンレスポンス
JWT 認可グラントフローのトークンレスポンスは RFC 6749 に準拠します。RFC 7523 では追加のレスポンスパラメーターは定義されていません。 唯一の注意点は、与えられた JWT が無効の際、error レスポンスパラメーターの値として invalid_grant を用いなければならないということです。
実装
JWT 認可グラントフローは Authlete 2.3 以降でサポートされます。/auth/token API のレスポンス
JWT 認可グラントフローをサポートするため、新しいアクション値 JWT_BEARER が追加されました。トークンリクエストの grant_type パラメーターの値が urn:ietf:params:oauth:grant-type:jwt-bearer で、当リクエストが Authlete サーバー側で実行される基本的なバリデーション処理をパスした場合、Authlete の /auth/token API からのレスポンス内の action レスポンスパラメーターの値は JWT_BEARER になります。
JWT 認可グラントフローをサポートするためには、認可サーバーの実装は JWT_BEARER アクションを処理しなければなりません。次に示す switch 文は authlete-java-jaxrs ライブラリの TokenRequestHandler.java から抜粋したもので、JWT_BEARER アクション処理の一つの例です。当 switch 文には JWT_BEARER 用の case エントリーがあります。
/auth/token API からのレスポンスに含まれる JWT 認可グラント関連のレスポンスパラメーターのリストです。
リクエストバリデーション
トークンリクエストのグラントタイプがurn:ietf:params:oauth:grant-type:jwt-bearer のとき、Authlete は (正確には Authlete の /auth/token API の実装は) 下記に示すバリデーション処理をこの順番で実施します。そのため、認可サーバーの実装は同じバリデーション処理を省略できます。
復号化用鍵を取得する標準的な方法が存在しないため、Authlete は暗号化された JWT のバリデーションをおこないません。これは、あなた自身で暗号化された JWT のバリデーションを実施しなければならないということを意味します。
JWT の署名を検証するための鍵を入手する標準的な方法が存在しないため、Authlete は JWT の署名検証をおこないません。これは、あなた自身で JWT の署名を検証しなければならないということを意味します。