Skip to main content
このページは Authlete 2.x 用です。3.0 のドキュメントはこちらをご覧ください。

Rich Authorization Requests (RAR)

はじめに

RFC 9396: OAuth 2.0 Rich Authorization Requests (RAR) は OAuth 2.0 の Proposed Standard 拡張仕様です。クライアントは従来の「スコープ」よりも細かな粒度の認可要件を JSON 構造で指定できるようになります。 本記事では、Authlete における RAR のサポートと、その機能を使って適切な粒度の権限を処理する方法を説明します。

RAR とは

リソースオーナーがサードパーティに付与した権限を表現するために、OAuth 2.0 認可フレームワーク は「スコープ」というしくみを導入しました。スコープに対し特定の意味を与えることにより、権限や機能オプションを表現できるようになります。 たとえば OpenID Connect 仕様では、“profile” のようなスコープを、“openid” スコープと同時に定義しています。“profile” スコープは、ユーザープロファイルの特定の属性 へのアクセス権限を、サードパーティに付与します。一方の “openid” スコープはセマンティクスが異なり、ID トークンの生成と UserInfo エンドポイントへのアクセス権限を意味します。 OAuth2 が普及するにつれて、新たなユースケースが登場し、それに対する新たなソリューションが必要となっています。RAR 仕様は、サードパーティがユーザーの承認を得る際にどのようなコンテキスト・意図があるかを示す必要があるケースに対処するものです。たとえば、オンライン決済や、ファイル共有、健康診断の結果などです。

RAR の構造

RAR は共通の JSON 構造を定義しています。この構造を用いて、より細かな粒度の権限を表現できます。それぞれの権限には、“type” 属性と、オプションである “locations” “actions” “datatypes” “identifier” “privileges” 属性、そして独自に定義された属性があります。詳細については Request parameter “authorization_details” セクションをご参照ください。 “type” 属性とそのセマンティクス(表現する内容や、その組み立て方、エンドユーザーに対する意図、そして属性間の関係など)をどう定義するかは、認可サーバー、もしくは認可サーバーが属するエコシステムに任されています。これにより、エンドユーザーに要求する権限を正確に定義できるようになります。 “locations” 属性は Resource Indicators 機構 と同じコンセプトであり、権限がどのリソースサーバー (の URI) に関するものかを指定するものです。“identifier” 属性は権限要求時に、特定リソースの指定に使えます。端的に言えば、“locations” はリソース群を示し、“identifier” は単一のリソースを指します。 “actions” は「動作」、たとえばファイルシステム上でのアクションや、銀行口座に関する操作、医療機器の制御、家電の挙動、データベースの権限などの表現に使えます。 “datatypes” と “privileges” は、要求する権限の特性を示す際に用います。

設定

Authlete の RAR のサポートはデフォルトで有効になっています。しかし、許諾する認可タイプは初期設定では存在していません。RAR を用いるためには、サービスレベルで認可タイプを設定し、クライアント単位で利用可能な認可タイプを指定する必要があります。

サービスレベルの設定

サポートする認可の “type” のリストの設定は管理者が行います。設定はサービスオーナーコンソールの「認可」タブにあります。この、サポートする “type” のリストが、クライアントからリクエスト可能な “type” になります。ただし、クライアントに対して自動的に利用可能になるものではありません。 Screen_Shot_2021-08-09_at_14 List of supported authorization types by a service

クライアント単位の設定

開発者コンソールにおいて、個別のクライアントごとに、リクエスト可能な認可の “type” を指定します。設定は「認可」タブにあります。 Screen_Shot_2021-08-09_at_14 List of authorization types that a client can request

利用例

認可リクエスト

認可リクエストの内容を「プッシュ」しなくても、あるいはリクエストオブジェクトを用いなくても、 RAR は利用可能です。ただし実際には、これらの併用が必須となる場合があります。もし RAR によって表現されるリクエストが非常に大きいときには PAR (Pushed Authorization Requests) が必須となるでしょう。また、もし改ざん防止を求めるのであれば JAR を使うべきです。 たとえばクライアントが、RAR を URL エンコードして、それを認可リクエストに含めて送信した場合、認可リクエストを受け取った認可サーバーから Authlete の /auth/authorization API へのリクエストは、以下のようになります。
  • リクエスト(レスポンスは省略)
この RAR の内容を、クライアントが JAR にラップした場合には、以下のサンプルのようになります。ここでは、Authlete が認可サーバーに、認可リクエストの内容をエコーバックしています。認可サーバーはこの内容をもとに、ユーザーの承認を確認します。
  • リクエスト
  • レスポンス

トークンリクエスト

ユーザーが承認した後に、認可サーバーは認可コードを生成し、それをクライアントへ返却します。クライアントは認可サーバーのトークンエンドポイントにアクセスします(必要であればそこでクライアント認証を受けます)。認可サーバーから呼び出された Authlete の /auth/token API は、アクセストークンと、もし openid スコープが指定されていれば ID トークンを生成します。 なお、ID トークンは認可詳細を含みません。
  • リクエスト
  • レスポンス

トークンイントロスペクション

アクセストークンを含む API リクエストを受信したリソースサーバーは、そのアクセストークンにどのような認可が与えられているかを確認するために、イントロスペクションエンドポイントを用います。そして、その API リクエストを処理するか、拒否するかを決定します。
  • リクエスト
  • レスポンス