金融APIにおけるOAuth2.0 Rich Authorization Requests の実践活用ガイド

はじめに

本稿では、FAPI 2.0でも推奨されている**RAR (Rich Authorization Requests)**という仕様の実践的な活用方法を解説します。
最近、OpenID FoundationもRARを推奨する記事と資料を公開していますので、ぜひ併せてご覧ください。
https://openid.net/standardized-fine-grained-authorization-with-oauth2-grant-management-and-rich-authorization-requests/

RAR(Rich Authorization Requests) とは

OAuth 2.0 Rich Authorization Requests (RAR、RFC 9396) は従来のscopeパラメータでは表現できなかった詳細な認可要求を構造化データとして伝達するための仕様です。
これにより特にオープンバンキングのユースケースで求められる特定口座のみへのアクセス許可といったfine-grainedな認可制御が可能になります。
scope は "accounts" のようなキーワードベースでアクセスを定義するため限界がある一方で、RARの authorization_details は JSON、つまり構造化された形式でアクセス権を表現できるため、「どの口座への読み取りを許可するか」といった具体的な文脈を持たせて、OAuth2フローの認可に組み込むことができます。authorization_detailsは認可リクエストパラメーターの一部であり、一般的に認可コードフローの中で利用されます。

https://datatracker.ietf.org/doc/html/rfc9396

オープンバンキングの世界におけるRAR採用状況

RAR自体、2023年5月にFinal化された比較的最近の仕様であるため実際に商用環境で実装し活用している認可サーバーはそう多くないのが実情です。
とはいえRFCとして標準化されているため、多くのIDaaSベンダー, もちろんAuthleteでもサポートされています。

オープンバンキングの世界では、これまでPSD2やOpenBanking UK仕様を源流とするConsent APIが広く活用されてきました。RARが実現するような、scope以上のきめ細やかなアクセス制御は、このConsent APIのパラメータで実現されてきた歴史があります。

その後、各国もConsent APIを標準仕様として取り入れられました。それらは英国の仕様などを参考にしつつも独自に策定されたため、仕様がそれぞれ微妙に異なっています。そこでOIDFが今日推奨しているのが、Grant ManagementとRARを組み合わせたアプローチです。

※ Grant ManagementもRAR同様、FAPI 2.0で推奨されている クライアントによる認可付与管理を実現する OAuth2.0 の標準仕様です。

OIDFは Grant Management + RAR と Consent / Intent API を以下のように比較整理しています。

比較項目	Grant Management + RAR	Consent / Intent API
標準化されているか	はい	いいえ
認可サーバーベンダーによるサポート	はい、すでに一部のベンダーが対応可能	相互運用可能な方法では非対応。現在の実装はカスタムで断片化されており、ベンダーロックインのリスクが高い。
セキュリティインフラの一部か	はい	いいえ ※（非標準の拡張であり、実装による）
OIDF適合テストスイートの一部か	はい、計画中	いいえ ※（カスタマイズ可能だが、標準化の主要成果に含まれない）
形式的なセキュリティ分析の対象か	はい、計画中	いいえ（標準化による主要成果ではない）
利用可能時期	現在利用可能（初期導入には若干の労力が必要） 多くの認可サーバーベンダーが、コア製品を変更せずに実装可能。 将来的には、ベンダーのコア製品の一部として統合されることで、導入コストが削減される。	現在利用可能（導入は比較的少ない労力で済むが、 非標準であり、セキュリティインフラの外側での実装が一般的）。 ただし、将来的に標準化されたソリューションに移行するには大きな労力が必要。
既存の実装者	開発中。現時点では本番環境での稼働はなし。 初期段階でのエコシステム導入を想定。	多数の非標準的かつ「スノーフレーク」な（エコシステムや導入ごとに異なる）実装が存在。
相互運用性	主要な設計目標	計画なし

個人的な見解ですが、FAPI 2.0 で RARや Grant Management が必須化されなかったのは、各国のオープンバンキングが Consent APIに依存しているため置き換えに対する status quoバイアスが強く働いたのではないかと思います。

オープンバンキング主要エリアの標準仕様におけるRAR採用状況を調べました。

Country	Specification	RAR Adoption
Australia	Consumer Data Right (CDR)	No
Brazil	Open Banking Brasil	No
EU	PSD2 (Revised Payment Services Directive)	No
UAE	Open Finance UAE	Yes
UK	OBIE (Open Banking Implementation Entity)	No
USA	Financial Data Exchange (FDX)	Yes

各国(※オープンバンキング先進国に限定)のRARの採用状況を調べたところ、FAPI 2.0を採用している事でも知られる米国のFDXと Open Finance UAE のみがRARを採用していることが分かりました。

対照的に オーストラリア（CDR）、ブラジル（Open Finance Brasil）、EU（PSD2）、英国（OBIE）といった他の主要な地域では現時点ではRARを採用しておらず、それぞれデータクラスター分類やConsentなどの従来的な仕様を用いて詳細な認可要求や同意管理を実現しています。

ケーススタディ

以上の調査から、RARを実装するにあたって参考にできる既存仕様は、RFCそのもの、そしてFDXとUAEのプロファイルとなります。これらはアプローチが少し異なります。

RFC

RFCでは、authorization_details内で利用できる共通フィールド（type, locations, actionsなど）が定義されています。type のみが必須で、それ以外は任意であり、また実装者が独自のカスタム項目を追加することも可能です。

[
   {
      "type": "customer_information",
      "locations": [
         "https://example.com/customers"
      ],
      "actions": [
         "read",
         "write"
      ],
      "datatypes": [
         "contacts",
         "photos"
      ]
   },
   {
      "type": "account_information",
      "actions": [
         "list_accounts",
         "read_balances",
         "read_transactions"
      ],
      "locations": [
         "https://example.com/accounts"
      ]
   },
   {
      "type": "payment_initiation",
      "actions": [
         "initiate",
         "status",
         "cancel"
      ],
      "locations": [
         "https://example.com/payments"
      ],
　　　　// 以下はカスタム項目
      "instructedAmount": {
         "currency": "EUR",
         "amount": "123.50"
      },
      "creditorName": "Merchant A",
      "creditorAccount": {
         "iban": "DE02100100109307118603"
      },
      "remittanceInformationUnstructured": "Ref Number Merchant"
   }
]

このRFCの特に実践的な仕様が Enriched Authorization Details in Token Response です。これは、ユーザーの同意内容に応じて、認可サーバーがauthorization_detailsの内容を「拡充」してトークン応答に含める機能です。

例えば、クライアントは「いずれかのアカウント情報へのアクセス」を要求し、ユーザーが同意画面で特定の口座（例：IBANがDE23...の口座）を選択したとします。

<-- Request -->
"authorization_details": [
   {
      "type": "account_information",
      "access": {
         "accounts": [],
         "balances": [],
         "transactions": []
      },
      "recurringIndicator":true
   }
]

<-- Token Response -->
   "authorization_details":[
      {
         "type":"account_information",
         "access":{
            "accounts":[
               {
                  "iban":"DE2310010010123456789"
               },
               {
                  "maskedPan":"123456xxxxxx1234"
               }
            ],
            "balances":[
               {
                  "iban":"DE2310010010123456789"
               }
            ],
            "transactions":[
               {
                  "iban":"DE2310010010123456789"
               },
               {
                  "maskedPan":"123456xxxxxx1234"
               }
            ]
         },
         "recurringIndicator":true
      }
   ]

https://datatracker.ietf.org/doc/html/rfc9396#name-enriched-authorization-deta

この仕組みにより、クライアントはユーザーがどのリソースへのアクセスを許可したかを、トークン取得時に直接知ることができます。これは、以下の図（Open Banking UKのガイドラインより引用）の④でユーザーが特定口座を選択するような体験を、OAuth2準拠の標準仕様で実現できます。

https://www.openbanking.org.uk/wp-content/uploads/2021/04/Customer-Experience-Guidelines-V3.1.3-web.pdf

RFC 以外(FDX および OpenFinance UAE)

では、RARを採用した実際のオープンバンキングプロファイルはどうかというと、現状ではいずれも既存のConsent APIとRARを組み合わせたハイブリッド型となっています。言い換えると、RFCが示す実装例とは少しかけ離れた形式になっています。(必須要件のみは準拠しているが)

具体的には、Consent APIで使われていたリクエストパラメータを、そのままauthorization_detailsの中に格納する形をとります。

FDX
FDX Confluence link

   "authorization_details":[
      {
         "type":"fdx_v1.0",
         "consentRequest":{
            "durationType":"ONE_TIME",
            "lookbackPeriod":60,
            "resources":[
               {
                  "resourceType":"ACCOUNT",
                  "dataClusters":[
                     "ACCOUNT_DETAILED",
                     "TRANSACTIONS",
                     "STATEMENTS"
                  ]
               }
            ]
         }
      }
   ]   

UAE
https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1final/pages/151850707/Bank+Data+Sharing+API+Guide

    "authorization_details": [
        {
            "type": "urn:openfinanceuae:account-access-consent:v1.0",
            "consent": {
                "ConsentId": "399e0065-9907-42cc-82b9-1ec4f273e3e9",
                "Permissions": [
                    "ReadAccountsBasic",
                    "ReadAccountsDetail",
                    "ReadBalances",
                    "ReadBeneficiariesBasic",
                    "ReadBeneficiariesDetail",
                    "ReadTransactionsBasic",
                    "ReadTransactionsDetail",
                    "ReadTransactionsCredits",
                    "ReadTransactionsDebits",
                    "ReadScheduledPaymentsBasic",
                    "ReadScheduledPaymentsDetail",
                    "ReadDirectDebits",
                    "ReadStandingOrdersBasic",
                    "ReadStandingOrdersDetail"
                ],
                "ExpirationDateTime": "2024-03-28T15:27:13+0300",
                "TransactionFromDateTime": "2024-03-25T12:19:24+0300",
                "TransactionToDateTime": "2024-03-27T12:19:24+0300",
                "AccountType": ["Retail"],
                "AccountSubType": ["CurrentAccount"]
            }
        }
    ] 

気になる点として、これらのプロファイルはRFCの「Enriched Authorization Details」は現時点では採用してないようです。ユーザーが同意した特定リソースの管理は、引き続き従来のConsent APIに委ねられているようです。

このハイブリッドアプローチは既存のConsentの仕組みを活かしながら段階的に標準仕様であるRARへ移行しようとしている意図があるのかもしれないのですが、少し中途半端な気もします。

一方で FDX と UAE が辿ったアプローチが類似している点は非常に興味深いです。

まとめ

本稿ではRARの概要からオープンバンキングにおける採用状況、そして具体的な実装パターンまでを解説しました。
RARはscopeで表現しきれない細かい認可を実現するOAuth2の標準仕様です。
オープンバンキング界では導入が限定的ですが、OIDFはGrant Managementとの組み合わせにより特に新規実装では推奨しており、相互運用性の高いエコシステムの鍵となり得ます。
現在の手法は、RFCが示す理想的なアプローチと、FDX/UAEに見られる既存資産を活かしたハイブリッドアプローチの2つが参考になります。
これから金融APIや、OAuth2ベースのより高度な認可制御が求められるシステムを設計する際にはまず標準仕様であるRARの採用を検討することをお勧めします。Consentに依存しているような既存システムであっても、FDXやUAEのハイブリッドアプローチは、標準へ移行するための現実的な戦略として非常に参考になるかと思いました。