セキュリティ改善とアプリケーション開発に活かせるOAuth 拡張仕様

Prepared for OAuth & OpenID Connect 勉強会by Authlete - 拡張仕様と適用例 https://www.authlete.com/ja/news/20240409_authlete-study-session/

OAuth 2.0 にはさまざまな拡張仕様が存在します。本プレゼンテーションでは、「セキュリティ改善」と「アプリケーション開発」の 2 つの観点から、これからの OAuth/OIDC 適用に際しておすすめの仕様を紹介します。

Transcript

1. セキュリティ改善と アプリケーション開発に活かせる OAuth 拡張仕様 工藤達雄 Authlete OAuth & OpenID Connect 勉強会 by Authlete - 拡張仕様と適用例
2. • OAuth 2.0 にはさまざまな拡張仕様が存在します。本プレゼンテーションで は、「セキュリティ改善」と「アプリケーション開発」の 2 つの観点か ら、これからの OAuth/OIDC 適用に際しておすすめの仕様を紹介します。 本プレゼンテーションの内容
3. 3 OAuth/OIDCのおさらい OpenID Provider (OP) Resource Owner User Agent Relying Party (RP) Authorization / Token EP UserInfo EP 認証リクエスト （スコープ + クレーム） 認証レスポンス （認可コード） Authorization Code Flow w/ Userinfo の例 • OpenID Connect: 「IDトークン」を 用いた「ID連携プロトコル」 ユーザーのことを 知りたい トークンリクエスト （認可コード） トークンレスポンス （アクセストークン + IDトークン） IDトークン検証 UserInfoリクエスト （アクセストークン） UserInfoレスポンス アクセストークン検証 （スコープ + クレーム） （完了） ユーザー認証・ 同意確認 （スコープ + クレーム） （スタート） UserInfoレスポンス 利用 ユーザーのことが わかる ユーザーのことが もっとわかる • OAuth 2.0: 「アクセストークン」を 用いた「API認可フレームワーク」 Resource Owner User Agent Client Authorization Server Resource Server Authorization Code Grant Flow / Bearer Token の例 認可リクエスト （スコープ） 認可レスポンス （認可コード） APIへのアクセス 権限をもらいたい トークンリクエスト （認可コード） トークンレスポンス （アクセストークン） APIリクエスト （アクセストークン） APIレスポンス アクセストークン検証 （スコープ） （完了） ユーザー認証・ 同意確認 （スコープ） （スタート） アクセス権限を 確認できる
4. 4 • 認可リクエスト – リダイレクトでどこまでいけるの? • アクセストークン – 盗まれたらそのまま使われてしまうの では? • スコープ – 複雑なアクセス権限をどう定義するの? • “OAuth Dance” – リソースオーナー/ユーザーエージェン トとクライアントのやりとりは必須? OAuth/OIDCの疑問あるある（ない?） Resource Owner User Agent Client Authorization Server Resource Server 認可リクエスト （スコープ） 認可レスポンス （認可コード） トークンリクエスト （認可コード） トークンレスポンス （アクセストークン） APIリクエスト （アクセストークン） APIレスポンス アクセストークン検証 （スコープ） （完了） （スタート） ユーザー認証・ 同意確認 （スコープ）
5. 5 • 認可リクエスト: リダイレクトでどこまでいけるの? → 認可リクエストの内容を直接送る! • アクセストークン: 盗まれたらそのまま使われてしまうのでは? → 正当なクライアントのみ使えるようにする! • スコープ: 複雑なアクセス権限をどう定義するの? → スコープの表現力を高める! • “OAuth Dance”: リソースオーナー/ユーザーエージェントとクライアントのやりとりは必須? → Decoupled Flow! そんな疑問に応えるOAuth/OIDC拡張仕様
6. 認可リクエスト リダイレクトでどこまでいけるの? 6
7. 7 • 認可サーバーがクライアントを 認証できない • リクエストの内容をユーザー エージェントから秘匿できない • 大きなサイズのリクエストを 送信できない 認可リクエストにまつわる様々な課題 Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可リクエスト 認可レスポンス トークンリクエスト トークンレスポンス APIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 認可 エンド ポイント トークン エンド ポイント API エンド ポイント
8. 8 • 認可サーバーがクライアントを 認証可能 • リクエストの内容をユーザー エージェントから秘匿可能 • 大きなサイズのリクエストを 送信可能 PAR (Pushed Authorization Requests - RFC 9126) 認可リクエストの「内容」を直接通信にて登録 Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可レスポンス トークンリクエスト トークンレスポンス APIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 PAR エンド ポイント request_uri を 含む認可リクエスト 「認可リクエスト の内容」登録 request_uri 返却 認可 エンド ポイント トークン エンド ポイント API エンド ポイント
9. 9 PAR (Pushed Authorization Requests - RFC 9126) PARエンドポイントへのリクエスト例 Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可レスポンス トークンリクエスト トークンレスポンス APIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 request_uri を 含む認可リクエスト 「認可リクエスト の内容」登録 request_uri 返却 PAR エンド ポイント 認可 エンド ポイント POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA& response_type=code& code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM& code_challenge_method=S256& redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb%2Fexample.com& client_id=CLIENT1234& scope=payment トークン エンド ポイント API エンド ポイント
10. アクセストークン 盗まれたらそのまま使われてしまうのでは? 10
11. 11 • 一般的に用いられるアクセス トークンは持参人 (Bearer) 型 – 盗まれたアクセストークンの 不正利用を防げない • Proof of Possession (PoP) – アクセストークンの提示時に、 自分が本当にその所持者である ことの証明 そのアクセストークンは誰のもの? Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可リクエスト 認可レスポンス トークンリクエスト トークンレスポンス APIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 PARリクエスト PARレスポンス PAR エンド ポイント 認可 エンド ポイント トークン エンド ポイント API エンド ポイント
12. 12 • 認可サーバーはクライアント （送信者）情報をひもづけた アクセストークンを発行 • リソースサーバーは APIリクエスト受付時に ひもづけを検証 • 何をひもづける? – クライアント証明書 (mTLS) – クライアントの公開鍵 (DPoP) Sender Constrained Access Token アクセストークンの「送信者」を限定 Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可リクエスト 認可レスポンス 送信者情報 + トークン リクエスト 送信者限定のアクセストークン + APIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 PARリクエスト PARレスポンス PAR エンド ポイント 認可 エンド ポイント トークン エンド ポイント API エンド ポイント 送信者限定の アクセストークン
13. 13 • クライアントが送信する トークンリクエストやAPI リクエストは通常のBearer トークンの場合と同様 • ただしクライアントは相互 TLS接続できることが前提 mTLS (Mutual-TLS Client Certificate-Bound Access Tokens - RFC 8705 Section 3) 相互TLS接続の「クライアント証明書」をひもづけ クライアント トークン EP 認可サーバー リソースサーバー 1b.相互TLS接続を通じて トークンリクエストを送信 3. アクセストークンを返却 2. クライアント 証明書にひもづく アクセストークン を生成 4b.相互TLS接続を通じて アクセストークンを含む リクエストを送信 API EP 5.クライアント 証明書とアクセス トークンの ひもづけを確認 1a: 相互TLS接続を確立 （クライアント証明書を提示） 4a: 相互TLS接続を確立 （クライアント証明書を提示） 0. クライアント 証明書を準備
14. 14 • DPoP Proof JWT – クライアントがJWK鍵ペア を生成し、その公開鍵と、 送信先のエンドポイントの 情報（HTTPメソッドと HTTPターゲットURI）など を含めて署名したもの – クライアントがHTTP ヘッダーに含めて送信 • クライアントはアプリケー ション層での対応が必要 • 一方、相互TLS接続は不要 DPoP (Demonstrating Proof-of-Possession - RFC 9449) “DPoP Proof JWT” の公開鍵をひもづけ トークン EP 3. トークンリクエスト用の “DPoP Proof JWT” を含む リクエストを送信 6. アクセストークンを返却 1. JWK鍵ペアを生成 4. “DPoP Proof JWT” を検証 2. 生成した鍵ペアを用いて トークンリクエスト用の “DPoP Proof JWT” （公開鍵を含む）を生成 5. “DPoP Proof JWT” の公開鍵に ひもづくアクセス トークンを生成 7. 生成した鍵ペアを用いて APIリクエスト用の “DPoP Proof JWT” （公開鍵を含む）を生成 8. API リクエスト用の “DPoP Proof JWT” とアクセストークン を含むリクエストを送信 API EP 9. “DPoP Proof JWT” を検証 10. “DPoP Proof JWT” の公開鍵と アクセストークン のひもづけを確認 クライアント 認可サーバー リソースサーバー
15. スコープ 複雑なアクセス権限をどう定義するの? 15
16. 16 APIにとって、ちょうどいいスコープとは? Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可リクエストにて 必要なスコープを要求 認可レスポンス トークンリクエスト トークンレスポンス スコープが付与されたアクセス トークンを用いてAPIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 認可 エンド ポイント トークン エンド ポイント スコープに 基づいてAPI リクエスト を処理 • スコープの例 – 対象リソースの範囲・種類、 リソースの参照・更新の区別、 特定の・期間限定の取引、… • OAuth 2.0のスコープ (scope) は たんなる文字列 (string) – profile, account:read, payment:12345678, … • 構造化やパラメータ化は可能だが 表現力に限界
17. 17 • 認可詳細 (authorization_details) – オブジェクトの配列を含むJSON – 認可リクエストの値として送信 – 認可決定やAPIアクセス認可に利用 RAR (Rich Authorization Requests - RFC 9396) 「認可詳細」によるスコープの表現力向上 Resource Owner User Agent Client Authorization Server Resource Server 認可レスポンス トークンリクエスト トークンレスポンス 認可詳細が付与された アクセストークンを用いてAPIリクエスト APIレスポンス （完了） ユーザー認証・ 同意確認 認可 エンド ポイント トークン エンド ポイント 認可詳細に 基づいてAPI リクエスト を処理 PAR エンド ポイント request_uri を 含む認可リクエスト 認可詳細登録 request_uri 返却 （スタート） [ { "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” } ] 口座情報参照・残高照会・取引履歴取得・決済指図を表現するauthorization_detailsの例
18. “OAuth Dance” リソースオーナー/ユーザーエージェントと クライアントのやりとりは必須? 18
19. デバイス 19 • 2つのサービスが、ユーザー起点で、ブラウザのリダイレクトによって連携する 従来の一般的な認証・認可フロー Source: HubSpot and Google API ブラウザ API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト 3. ログイン 1. サービス利用試行 ユーザー
20. 20 • 「ブラウザのリダイレクト」が無くなり、分離されたデバイス同士は直接連携しない。 認証・認可は「公式モバイルアプリ」が実施 デバイスを “API利用” と ”認証・認可” に分離 1. サービス利用試行 ユーザー スマート スピーカー スマート フォン デバイスを分離 太郎さんに 5,000円 送金して API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト API 3. 銀行Appにて ユーザー認証・ 取引承認
21. デバイス 21 • ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの手元の銀行Appが 取引承認を求める ユーザーが所有しないデバイスと連携 1. サービス利用試行 ユーザー 会員証 提示 3. 銀行Appにて ユーザー認証・ 取引承認 お支払合計 ￥1,234 スマート フォン デバイス POS端末 API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト API
22. 認証・認可 / API サーバー 2. 認証・認可 リクエスト 22 • コールセンターのオペレーターに購入を伝えると（カード情報等は教えない） ユーザーの手元の銀行Appが取引承認を求める ユーザー以外の誰かがサービスを利用 API クライアント コールセンター端末 テレフォン オペレーター 1. サービス利用試行 スマート フォン ユーザー 3. 銀行Appにて ユーザー認証・ 取引承認 TVショッピングを 観て購入の電話 API
23. • APIプロバイダー自らが確実にユーザー認証・認可を実施 • オフラインとオンラインを融合し、さらにオフライン側のデバイスや操作者を分離 CIBA (Client Initiated Backchannel Authentication) ユーザー ユーザー認証・ API認可デバイス 利用 認証 API 利用デバイス ユーザー or 第三者 認証・認可 リクエスト クライアント （リライング・ パーティ） 認可・APIサーバー （アイデンティティ・ プロバイダー） 23
24. CIBAフロー Consumption Device (CD) Authentication Device (AD) クライアント （リライング パーティ） 認可・APIサーバー (アイデンティティ プロバイダー) 0 0. ユーザーの識別子を 判別 login_hint_token id_token_hint login_hint Backchannel Authentication EP 2b 2b. ユーザー 認証 API (*) Access Token (**) Refresh Token 1 1. 認証リクエストを送信 ユーザー識別子 2a 2a. 「認証リクエストID」 を返却 AuthN Req ID 4a AT 4a. トークンを用いて APIアクセス 4b ID Token 4b. 認証結果を用いて ユーザーを識別 24 3 ID Token / AT* / (RT**) 3. 認証結果とトークンを 返却（Pollモード） Token EP
25. まとめ 25
26. OAuth/OIDC拡張仕様を活用しましょう! 26 • セキュリティの改善 – PAR: 認可リクエスト の内容を直接送信 – mTLS & DPoP: アクセストークンの 送信者を限定 • アプリケーション 開発への活用 – RAR: スコープの 表現力を向上 – CIBA: “Decoupled Flow” • そして “FAPI 2.0” へ Resource Owner User Agent Client Authorization Server Resource Server 認可リクエスト (request_uri) request_uri 返却 認可レスポンス （認可コード） トークンリクエスト （認可コード） APIリクエスト （アクセストークン） APIレスポンス （アクセストークン） （スタート） （完了） 認可リクエストの 内容（認可詳細） 認可詳細 (RAR) を 直接送信 (PAR) トークンレスポンス （アクセストークン） 送信者限定アクセス トークンを返却 (mTLS/DPoP) アクセストークン検証 （認可詳細） アクセストークンを検証 (RAR + mTLS/DPoP) ユーザー認証・ 同意確認（認可詳細） 認可詳細に関する 同意確認 (RAR)
27. Thank You www.authlete.com info@authlete.com Palo Alto, Tokyo, Dubai