Apigee の FAPI & CIBA 対応を実現する 「Authlete（オースリート）」

Prepared for Apigee Meetup Japan #4

Transcript

1. Apigee の FAPI & CIBA 対応を実現する 「Authlete（オースリート）」 ⼯藤達雄 Authlete, Inc.
2. 2 • ⽇本のAPIセキュリティスタートアップ • OAuth 2.0 & OpenID Connect (OIDC) サーバーを実装 するために必要な機能をAPIとして提供 • 他社に先駆けて FAPI & CIBAを実装 – ⽶国OpenID財団の 認定を世界初取得 Authlete社
3. 3 FAPI & CIBA: “セキュリティ” と ”チャネル” セキュリティ チャネル FAPI Financial-grade API ⾼付加価値APIに必要な セキュリティ基準 CIBA Client Initiated Backchannel Authentication モバイルによるオンライン・ オフラインの融合 OAuth 2.0 / OpenID Connect
4. 4 • ⾼いセキュリティが求められる API向けのOAuth 2.0詳細仕様 • アクセストークンの授受・利⽤に かかるセキュリティ対策を標準化 • 2021年3⽉にFAPIバージョン1が確定 • 現在 FAPI 2.0 の策定が進⾏中 FAPI (ファピ) Source: OpenID Foundation
5. 5 FAPI ”OAuth 2.0” の典型的な課題 Resource Owner User Agent Client Authorization Server Resource Server （スタート） 認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス API リクエスト API レスポンス （完了） ユーザー認証・ アクセス承認 認可リクエストの 改ざん 認可レスポンスの 改ざん クライアントの なりすまし アクセストークン の盗⽤ リクエスターの ⼊れ替わり
6. 6 FAPI OIDCとOAuth 2.0拡張仕様によるセキュリティ強化 Resource Owner User Agent Client Authorization Server Resource Server （スタート） リクエストオブジェクト & PKCEを⽤いた認可リクエスト “Hybrid Flow” or JARMを⽤いた 認可レスポンス private_key_jwt or mTLS を⽤いた トークンリクエスト トークン レスポンス Certificate Bound Access Token を⽤いたAPIリクエスト API レスポンス （完了） ユーザー認証・ アクセス承認 認可リクエスト への署名付与 認可レスポンス への署名付与 公開鍵暗号による クライアント認証 クライアント限定 アクセストークン リクエストの ひもづけ
7. 7 • 英国 Open Banking – 上位9⾏に、FAPIを基盤とする共通APIを義務化 – 他の銀⾏も⾃発的に採⽤ • ⽶国 & カナダ – 業界団体のFinancial Data Exchange がセキュリティ プロファイルとしてFAPIを採⽤ • 豪州 Consumer Data Right – 銀⾏だけではなく通信やエネルギー分野まで含めた 統⼀的なAPIの基盤としてFAPIを採⽤ • ブラジル Open Finance – 銀⾏だけではなく、保険、年⾦、資本⾦、外国為替、 投資データも対象 • その他 – Nigeria, New Zealand, Russia, Saudi Arabia, … – ISO TC68 SC9 WG2 - WAPI FAPI ⾦融APIセキュリティの事実上の標準 Source: OpenID Foundation https://openid.net/wordpress-content/uploads/2022/03/OIDF-Whitepaper_Open-Banking-Open-Data-and-Financial-Grade-APIs_2022-03-16.pdf, Platformable https://platformable.com/open-banking/trends/
8. 8 • さまざまな局⾯でのユーザー認証・同意確認に 「公式モバイルアプリ」を⽤いるためのしくみ CIBA (シーバ)
9. デバイス 9 • 2つのサービスが、ユーザー起点で、ブラウザのリダイレクトによって連携する CIBA 従来の⼀般的な認証・認可フロー Source: HubSpot and Google API ブラウザ API クライアント 認証・認可 / API サーバー 1. サービス利⽤試⾏ 2. 認証・認可 リクエスト 3. ログイン ユーザー
10. 10 • 「ブラウザのリダイレクト」が無くなり、分離されたデバイス同⼠は直接連携しない。 認証・認可は「公式モバイルアプリ」が実施 CIBA デバイスを “API利⽤側” と ”認証・認可側” に分離 1. サービス利⽤試⾏ スマート スピーカー スマート フォン ユーザー 太郎さんに 5,000円 送⾦して 3. 銀⾏Appにて ユーザー認証・ 取引承認 デバイスを分離 API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト API
11. デバイス デバイス 11 • ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの⼿元の銀⾏Appが 取引承認を求める CIBA ユーザーが所有しないデバイスと連携 POS端末 1. サービス利⽤試⾏ 3. 銀⾏Appにて ユーザー認証・ 取引承認 ユーザー 会員証 提⽰ お⽀払合計 ￥1,234 スマート フォン API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト API
12. API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト 12 • コールセンターのオペレーターに購⼊を伝えると（カード情報等は教えない） ユーザーの⼿元の銀⾏Appが取引承認を求める CIBA ユーザー以外の誰かがサービスを利⽤ コールセンター端末 テレフォン オペレーター 1. サービス利⽤試⾏ 3. 銀⾏Appにて ユーザー認証・ 取引承認 スマート フォン ユーザー TVショッピングを 観て購⼊の電話 API
13. 13 • APIプロバイダー⾃らが確実にユーザー認証・認可を実施 • オフラインとオンラインを融合し、さらにオフライン側のデバイスや操作者を分離 CIBA セキュリティを担保し適⽤分野を拡⼤ ユーザー ユーザー認証・ API認可デバイス 利⽤ 認証 API 利⽤デバイス ユーザー or 第三者 認証・認可 リクエスト クライアント （リライング・ パーティ） 認可・APIサーバー （アイデンティティ・ プロバイダー）
14. 14 • API基盤⾃体がFAPI ＆ CIBA対応していれば良いが… • OSS等を活⽤しスクラッチから実装 – 仕様が複雑であり開発・運⽤の難易度が⾼い • IDaaS等のオールインワンソリューションを導⼊ – UI/UXのカスタマイズやユーザー情報移⾏が難しい → 「実装の外部化」と「柔軟性・統制⼒」が必要 FAPI & CIBAをどうAPI基盤に追加するか?
15. Authlete: OAuth/OIDC Component as a Service Identity Assurance Financial- grade API OAuth 2.0 & OpenID Connect 自社アプリ & Webサイト Fintech 事業者 他社 サービス OAuth 2.0 & OpenID Connect プロトコル処理 アクセストークン ライフサイクル管理 業界標準の API認可とID連携 更新系を含む オープンAPIの提供 当人の同意に基づく KYC情報の共有 OAuth 2.0 & OpenID Connect プロトコル処理 アクセストークン ライフサイクル管理 最先端の業界標準API仕様に準拠 特定ソリューションに依存せず自由にUX設計が可能 OAuth 2.0 & OpenID Connect に関する複雑な実装・運用を外部化 サービス事業者 銀⾏・Fintech・メディア・SaaS・ ヘルスケア・エンタメ・ECなど 柔軟な開発・運用が可能 15
16. 認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス API リクエスト API レスポンス ユーザー認証・ アクセス承認 エンド ユーザー ユーザー エージェント クライアント OAuth/OIDC サーバー リソース サーバー リクエストをAuthleteに転送するだけでOK 認可リクエストを 「そのまま」転送 エンドユーザーに ひもづく認可コード の発⾏を依頼 トークンリクエストを 「そのまま」転送 イントロス ペクション を依頼 Authlete Authlete OAuth/OIDC サーバーが次に することを Authlete API が指示 { "parameters": "response_type=code& client_id=57297408867& redirect_uri=https%3A%2F%2F client.example.org%2Fcb" }' { ”action”: ”INTERACTION”, ”ticket”: ”c4iy3TWUzV9axH-9Q” ... } https://as.example.com/authorize? response_type=code& client_id=57297408867& redirect_uri=https%3A%2F%2F client.example.org%2Fcb リクエストを 検証・解析 /auth/authorization POST 16
17. 17 どのようなサービス構成にも適合可能 専⽤OAuth/OIDCサーバー構築パターン APIゲートウェイ組み込みパターン IAM機能強化パターン Webサービス⼀体化パターン
18. 認可 バックエンド API トークン管理 データベース バックエンド API 管理基盤 Apigee リクエスト ApigeeのOAuth/OIDC処理をAuthleteに移管 アイデンティティ&アクセス管理 認可ロジック （認可判定） ユーザー 認証 同意確認 権限管理 API 認可リクエスト （トークン取得） API アクセス (トークン利⽤) 認可状態確認（トークン検証など） OAuth/OIDC 処理リクエスト（認可コード/トークン発⾏など） OAuth エンド ポイント API エンド ポイント APIクライ アント Webサイト 携帯端末 ネットワーク デバイス
19. ⾃⾏モバイル向け API認可基盤を構築し さらにFAPI準拠の オープンAPIを実装 • ゼロベースで設計された 次世代のデジタルバンク • Google Cloudとの親和性の ⾼さからAuthleteを採⽤ • Authleteのマネージドサービス を利⽤し運⽤負荷低減 • OAuth/FAPIの進化に適応可能 な基盤構築を迅速に実現 事例: みんなの銀⾏ 19
20. Sample Customers and Partners *1 LINE Bank設立準備株式会社 楽天銀⾏ LINE Bank *1 20 DPG Media NTT Docomo Nubank セブン&アイ
21. 21 • FAPI – OAuth 2.0のセキュリティを⾼めるための詳細仕様 – ⾦融サービスAPIを中⼼に事実上の標準となりつつある • CIBA – APIプロバイダーの「公式モバイルアプリ」による認証・認可 – APIの許可と利⽤を分離し、オンラインとオフラインを融合 • Authlete – OAuth/OIDCからFAPI/CIBAまで、実装に必要な機能をAPIとして提供 – ApigeeのバックエンドAPIとして組み込み可能 まとめ
22. Thank You tatsuo.kudo@authlete.com www.linkedin.com/in/tatsuokudo