Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Apigee の FAPI & CIBA 対応を実現する 「Authlete(オースリート)」
Search
Tatsuo Kudo
December 02, 2022
Technology
0
5
Apigee の FAPI & CIBA 対応を実現する 「Authlete(オースリート)」
Prepared for Apigee Meetup Japan #4
Tatsuo Kudo
December 02, 2022
Tweet
Share
More Decks by Tatsuo Kudo
See All by Tatsuo Kudo
MCPから考えるOAuth/OIDCの現状と展望
tkudo
0
3
BaaS基盤におけるAPIセキュリティの 課題と実装
tkudo
0
3
人とAPIをつなぐ「認証・認可」
tkudo
0
7
「OAuth/OIDC 化」の考えかた
tkudo
0
3
Striking the Right Balance — Compliance, Security and User Experience
tkudo
0
4
セキュリティ改善とアプリケーション開発に活かせるOAuth 拡張仕様
tkudo
0
3
FAPIを中心とするAPI標準化の動向
tkudo
0
3
OAuth 2.0とOpenID Connectの細かい話
tkudo
0
2
SAMLからOpenID Connectへ - フェデレーション技術の広がり
tkudo
0
1.5k
Other Decks in Technology
See All in Technology
ZennとCloud Runの歩み - プロダクト開発に全集中できる相棒になるまで
wadayusuke
5
620
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
200
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
9
3.5k
AI時代に活躍できるエンジニアとは #弁護士ドットコム
bengo4com
0
250
いまさら聞けない ABテスト入門
skmr2348
0
170
Railsアプリケーション開発者のためのブックガイド
takahashim
12
5.1k
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
260
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
pprof vs runtime/trace (FlightRecorder)
task4233
0
140
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
3
840
Deep Research と NotebookLM を使い倒す!レガシーリプレイスの技術選定と学習コスト削減術
tet0h
0
2.8k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
Featured
See All Featured
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
We Have a Design System, Now What?
morganepeng
53
7.8k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
32
2.2k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Making Projects Easy
brettharned
118
6.4k
Why Our Code Smells
bkeepers
PRO
339
57k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Balancing Empowerment & Direction
lara
4
660
Transcript
Apigee の FAPI & CIBA 対応を実現する 「Authlete(オースリート)」 ⼯藤達雄 Authlete, Inc.
2 • ⽇本のAPIセキュリティスタートアップ • OAuth 2.0 & OpenID Connect (OIDC)
サーバーを実装 するために必要な機能をAPIとして提供 • 他社に先駆けて FAPI & CIBAを実装 – ⽶国OpenID財団の 認定を世界初取得 Authlete社
3 FAPI & CIBA: “セキュリティ” と ”チャネル” セキュリティ チャネル FAPI
Financial-grade API ⾼付加価値APIに必要な セキュリティ基準 CIBA Client Initiated Backchannel Authentication モバイルによるオンライン・ オフラインの融合 OAuth 2.0 / OpenID Connect
4 • ⾼いセキュリティが求められる API向けのOAuth 2.0詳細仕様 • アクセストークンの授受・利⽤に かかるセキュリティ対策を標準化 • 2021年3⽉にFAPIバージョン1が確定
• 現在 FAPI 2.0 の策定が進⾏中 FAPI (ファピ) Source: OpenID Foundation
5 FAPI ”OAuth 2.0” の典型的な課題 Resource Owner User Agent Client
Authorization Server Resource Server (スタート) 認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス API リクエスト API レスポンス (完了) ユーザー認証・ アクセス承認 認可リクエストの 改ざん 認可レスポンスの 改ざん クライアントの なりすまし アクセストークン の盗⽤ リクエスターの ⼊れ替わり
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 • 英国 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 • さまざまな局⾯でのユーザー認証・同意確認に 「公式モバイルアプリ」を⽤いるためのしくみ CIBA (シーバ)
デバイス 9 • 2つのサービスが、ユーザー起点で、ブラウザのリダイレクトによって連携する CIBA 従来の⼀般的な認証・認可フロー Source: HubSpot and Google
API ブラウザ API クライアント 認証・認可 / API サーバー 1. サービス利⽤試⾏ 2. 認証・認可 リクエスト 3. ログイン ユーザー
10 • 「ブラウザのリダイレクト」が無くなり、分離されたデバイス同⼠は直接連携しない。 認証・認可は「公式モバイルアプリ」が実施 CIBA デバイスを “API利⽤側” と ”認証・認可側” に分離
1. サービス利⽤試⾏ スマート スピーカー スマート フォン ユーザー 太郎さんに 5,000円 送⾦して 3. 銀⾏Appにて ユーザー認証・ 取引承認 デバイスを分離 API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト API
デバイス デバイス 11 • ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの⼿元の銀⾏Appが 取引承認を求める CIBA ユーザーが所有しないデバイスと連携 POS端末 1.
サービス利⽤試⾏ 3. 銀⾏Appにて ユーザー認証・ 取引承認 ユーザー 会員証 提⽰ お⽀払合計 ¥1,234 スマート フォン API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト API
API クライアント 認証・認可 / API サーバー 2. 認証・認可 リクエスト 12
• コールセンターのオペレーターに購⼊を伝えると(カード情報等は教えない) ユーザーの⼿元の銀⾏Appが取引承認を求める CIBA ユーザー以外の誰かがサービスを利⽤ コールセンター端末 テレフォン オペレーター 1. サービス利⽤試⾏ 3. 銀⾏Appにて ユーザー認証・ 取引承認 スマート フォン ユーザー TVショッピングを 観て購⼊の電話 API
13 • APIプロバイダー⾃らが確実にユーザー認証・認可を実施 • オフラインとオンラインを融合し、さらにオフライン側のデバイスや操作者を分離 CIBA セキュリティを担保し適⽤分野を拡⼤ ユーザー ユーザー認証・ API認可デバイス
利⽤ 認証 API 利⽤デバイス ユーザー or 第三者 認証・認可 リクエスト クライアント (リライング・ パーティ) 認可・APIサーバー (アイデンティティ・ プロバイダー)
14 • API基盤⾃体がFAPI & CIBA対応していれば良いが… • OSS等を活⽤しスクラッチから実装 – 仕様が複雑であり開発・運⽤の難易度が⾼い •
IDaaS等のオールインワンソリューションを導⼊ – UI/UXのカスタマイズやユーザー情報移⾏が難しい → 「実装の外部化」と「柔軟性・統制⼒」が必要 FAPI & CIBAをどうAPI基盤に追加するか?
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
認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス 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 どのようなサービス構成にも適合可能 専⽤OAuth/OIDCサーバー構築パターン APIゲートウェイ組み込みパターン IAM機能強化パターン Webサービス⼀体化パターン
認可 バックエンド API トークン管理 データベース バックエンド API 管理基盤 Apigee リクエスト
ApigeeのOAuth/OIDC処理をAuthleteに移管 アイデンティティ&アクセス管理 認可ロジック (認可判定) ユーザー 認証 同意確認 権限管理 API 認可リクエスト (トークン取得) API アクセス (トークン利⽤) 認可状態確認(トークン検証など) OAuth/OIDC 処理リクエスト(認可コード/トークン発⾏など) OAuth エンド ポイント API エンド ポイント APIクライ アント Webサイト 携帯端末 ネットワーク デバイス
⾃⾏モバイル向け API認可基盤を構築し さらにFAPI準拠の オープンAPIを実装 • ゼロベースで設計された 次世代のデジタルバンク • Google Cloudとの親和性の
⾼さからAuthleteを採⽤ • Authleteのマネージドサービス を利⽤し運⽤負荷低減 • OAuth/FAPIの進化に適応可能 な基盤構築を迅速に実現 事例: みんなの銀⾏ 19
Sample Customers and Partners *1 LINE Bank設立準備株式会社 楽天銀⾏ LINE Bank
*1 20 DPG Media NTT Docomo Nubank セブン&アイ
21 • FAPI – OAuth 2.0のセキュリティを⾼めるための詳細仕様 – ⾦融サービスAPIを中⼼に事実上の標準となりつつある • CIBA
– APIプロバイダーの「公式モバイルアプリ」による認証・認可 – APIの許可と利⽤を分離し、オンラインとオフラインを融合 • Authlete – OAuth/OIDCからFAPI/CIBAまで、実装に必要な機能をAPIとして提供 – ApigeeのバックエンドAPIとして組み込み可能 まとめ
Thank You
[email protected]
www.linkedin.com/in/tatsuokudo