Prepared for Apigee Meetup Japan #4

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