Prepared for a workshop held by Tokyo Digital Ideas in September 15, 2022

1. 金融APIセキュリティの動向・事例と
今後の方向性
工藤達雄
Authlete, Inc.

2. 2
• 「オープンAPI」の現在
• FAPI&CIBA: 注目すべき技術標準
• 国内外の事例
• 進化するアイデンティティアーキテクチャ
Agenda

3. 3
• サン・マイクロシステムズ、
野村総合研究所、NRI セキュアを
経て、2018年 Authlete に入社
• デジタルアイデンティティを
中心とするプリセールス・
コンサルティング・事業開発・
エバンジェリズムに従事
About Me

4. 「オープンAPI」の現在

5. • 例: 銀行
– 「オープンデータ」の提供
• 支店の住所情報など
– コア機能のホワイトレーベル提供
• “Bank as a Service”
– お客さまに関わるデータ・機能の
提供
• 口座情報・契約情報・取引履歴な
どのデータ、取引の実行機能など
金融サービスにおける「オープンAPI」とは
約2.5万API中、Bankingカテゴリに登録されているのは607種類
Source:https://www.programmableweb.com/category/banking
5

6. 6
• APIとして提供された
金融機能 (finance) が
事業者のサービスに
埋め込まれる (embedded)
– 「保険機能」が
「ECサイト」に
– 「ローン機能」が
「高価な買い物」に
– 「送金機能」が
「B2B SaaS事業者」に
オープンAPIが実現する “Embedded Finance”
Source:三井物産戦略研究所
https://www.mitsui.com/mgssi/ja/report/detail/__icsFiles/afieldfile/2021/03/16/2103i_onishi.pdf

7. 7
Embedded Finance エコシステムの例
Source:NTTデータ経営研究所
https://www.meti.go.jp/meti_lib/report/2021FY/000116.pdf

8. 8
• 国内のほぼすべての銀行がAPIを準備済み
– ほとんどの銀行がAPIまたは暫定スクレイピング契約締結
済み（2020年9月末時点）
– 約8割の銀行がAPI提供中もしくは準備段階（2021年度）
• しかしサードパーティからのAPI接続は低調 (2020年9月
末時点)
– 88電代業者中、APIまたは暫定スクレイピング契約締結済
みは39社(約45%)
– 契約締結済みであっても、1~2銀行としか締結していない
電代業者が過半数
• 更新系APIの提供は限定的（2021年度）
– 提供中と回答した金融機関は個人更新系は全体の10.1％、
法人更新系は7.1％
国内のオープンAPIは “Embeddable” か?
Source:金融庁 https://www.fsa.go.jp/status/keiyakujoukyou_api/index.html,
FISC https://www.fisc.or.jp/document/fintech/file/FinTech_20220225_05.pdf

9. 9
現時点では「機能」と「チャネル」が不足
機能
チャネル
Embedded
Finance
• 参照系中心
• オンライン限定

10. 10
「更新系」と「オフライン」
機能
チャネル
Embedded
Finance
• 参照系中心
• オンライン限定
更新系の拡充
オフラインへの拡大

11. 11
セキュリティの “FAPI” とモバイルの “CIBA”
機能
チャネル
Embedded
Finance
FAPI
Financial-grade API
高付加価値APIに必要な
セキュリティ基準
CIBA
Client Initiated Backchannel
Authentication
モバイルによるオンライン・
オフラインの融合

12. FAPI&CIBA: 注目すべき技術標準

13. 13
• アクセストークンによる API
認可
– ユーザーのID/パスワードや
“APIキー” の流出を防止
• エンドユーザーによる同意確
認
– ユーザーがクライアントにアク
セス範囲・期限を許諾
• ”OpenID Connect” への拡張
– API認可とID連携を同時に処理
APIセキュリティに欠かせない “OAuth 2.0”
エンドユーザー
API サーバー
API クライアント 4. アクセストークン
を含むAPIリクエスト
3. アクセス
トークンを
発行
2. ユーザー認証と
APIアクセス認可
1. 認可プロセス開始

14. 14
• オープンAPIのあり方に関する検討会報告書
（2017年７月13日） https://www.zenginkyo.or.jp/abstract/council/openapi/
– “「認可プロトコル」として、OAuth2.0 認可フレームワーク（以下「OAuth2.0」
という。）を推奨する。なお、金融分野における API への OAuth2.0 の適用に
関する詳細仕様は、2017 年６月現在、OpenID Foundation Financial API WG（FAPI
WG）において、セキュリティ水準を確保する観点から、標準化作業が実施さ
れている。同団体で OAuth2.0 適用の詳細仕様が発行された際には、各銀行にお
いて同仕様への準拠や準拠に向けた方針等が検討されることが望ましい。”
• 金融機関とAPI接続先のためのAPI接続チェックリスト（2019年９月27日一部改訂）
https://www.fisc.or.jp/document/fintech/004194.php
– “通番 36: 認証認可に関する機密情報の漏洩対策を実施する。[…] 本項目に関連して
実施する手法例は、以下が考えられる。＜トークンの適切な管理＞１．利用する
API のセキュリティリスクに応じた適切なトークンの管理を実施している。 […]”
– “通番 37: API の想定外利用を回避する。 […] 利用する API の範囲や、取得するトー
クンによって実現できる機能を理解している。 […] OAuth2.0の仕組みを理解してお
り、それに関連する項目の意味を説明することができる。”
OAuth 2.0の利用を全銀協やFISCが推奨・前提化

15. 15
• 高いセキュリティが求められる（”金融グレード” の）
API向けのOAuth 2.0詳細仕様
– アクセストークンの授受・利用にかかるセキュリティ対策を
標準化
– 2021年3月にFAPIバージョン1が確定
• 金融機関における FAPI 採用の利点
– 独自詳細仕様の開発・運用に費やすコストの削減
– 高度な OAuth 2.0 セキュリティの担保
– FAPI 実装の「認定プログラム」を活用可能
• FAPI 準拠の有無をソフトウェア調達にて評価
• 認定テストスイートを用いて自行の FAPI 実装を継続的にテスト
し、機能低下（デグレ）を防止
FAPI (ファピ)

16. FAPI による不正なトークン授受・利用の防止
Fintech事業者
攻撃者
金融機関
OAuth2 アクセス認可リクエスト
認可レスポンス・トークン付与
トークン付きAPIリクエスト（参照・更新）
r電子署名により真正性を担保し
不正なトークン授受を防止
トークン窃取
相互TLSにより
リクエスト送信者を特定し
トークンの不正利用を防止
窃取したトークンを用いた
「なりすましアクセス」を
検知しリクエストを拒否
16

17. 17
• さまざまな局面でのユーザー認証・同意確認を
「金融機関公式モバイルアプリ」を用いて直接実施
するためのサービス連携のしくみ
CIBA (シーバ)

18. デバイス
従来の一般的な認証・認可フロー
2つのサービスが、ユーザー起点で、ブラウザのリダイレクトによって連携する
Source: HubSpot and Google
API
ブラウザ
API
クライアント
認証・認可 /
API サーバー
18
1. サービス利用試行
2. 認証・認可
リクエスト
3. ログイン
ユーザー

19. デバイスを “API利用側” と ”認証・認可側” に分離
「ブラウザのリダイレクト」が無くなり、分離されたデバイス同士は直接連携しない
1. サービス利用試行
2. 認証・認可
リクエスト
API
クライアント
スマート
スピーカー
スマート
フォン
ユーザー
認証・認可 /
API サーバー
太郎さんに
5,000円
送金して
3. 銀行Appにて
ユーザー認証・
取引承認
19
デバイスを分離

20. デバイス
デバイス
ユーザーが所有しないデバイスと連携
ショッピングセンターのPOS端末に会員証をかざすと、ユーザーの手元の銀行Appが取引承認を求める
POS端末
1. サービス利用試行
2. 認証・認可
リクエスト
API
クライアント
認証・認可 /
API サーバー
3. 銀行Appにて
ユーザー認証・
取引承認
ユーザー
会員証
提示
お支払合計
￥1,234
20
スマート
フォン

21. ユーザー以外の誰かがサービスを利用
コールセンターのオペレーターに購入を伝えると（カード情報等は教えない）、ユーザーの手元の銀行Appが取引承認を求める
コールセンター端末
テレフォン
オペレーター
1. サービス利用試行
2. 認証・認可
リクエスト
API
クライアント
認証・認可 /
API サーバー
3. 銀行Appにて
ユーザー認証・
取引承認
スマート
フォン
ユーザー
TVショッピングを
観て購入の電話
21

22. 22
• 金融機関自らが確実にユーザー認証・認可を実施
– サードパーティではなく「銀行公式アプリ」を使用するため、金融グレードの認証・認可ができる
• オフラインとオンラインを融合
– さらに、オフライン側のデバイスやそれを操作する人間はエンドユーザーから離れていても良い
セキュリティを担保しつつ適用分野を拡大
ユーザー
ユーザー認証・
API認可デバイス
利用 認証
API 利用デバイス
ユーザー or 第三者
認証・認可
リクエスト
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）

23. 国内外の事例

24. 24
• 英国Open Banking
– 上位9行に、FAPIを基盤とする共通APIを義務
化。他の銀行も自発的に採用し、APIの統一
が実現
• 米国 & カナダ
– 業界団体のFinancial Data Exchange がセキュ
リティプロファイルとしてFAPIを採用
• 豪州 Consumer Data Right
– 銀行だけではなく通信やエネルギー分野まで
含めた統一的なAPIの基盤としてFAPIを採用
• ブラジルOpen Banking
– （次ページ）
• その他
– Nigeria
– New Zealand
– Russia
– ISO TC68 SC9 WG2 - WAPI
グローバルに進む FAPI (& CIBA) 採用
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/

25. 25
• 2019年、ブラジル中央銀行がオープンバンキングプロジェクトを承認
– The Open Banking implementation in Brazil is inserted in the BCB's
institutional mission: "to foster a sound, efficient, and competitive
financial system, and to promote the economic well-being of society”
• 規制主導モデル
– In order to ensure compliance with the regulation and the achievement
of the Open Banking's objectives, the BCB has been coordinating the
initial self-regulatory efforts by approving decisions and revisions, as well
as exercising the veto power, imposing restrictions or regulating
nonagreed aspects.
• 段階的にオープン化
– 2021年2月 (フェーズ1): オープンデータ（金融機関自身のデータ共有）
– 2021年後半 (フェーズ2): ユーザー自身のデータ（アカウント、カー
ド、クレジット業務に関する登録・取引データ）共有
– 2021年10月 (フェーズ3): Pixによる決済指図サービスの開始
– 2022年初頭~: 既存フェーズの修正・拡張を実施中
• 2022年3月、”Open Banking” から ”Open Finance” へ変更決定
– 銀行だけではなく、保険、年金、資本金、外国為替、投資データも対
象に
ブラジル Open Banking → Open Finance
Source: Banco Central Do Brasil https://www.bcb.gov.br/en/financialstability/open_banking,
Open Banking Brasil https://openbankingbrasil.org.br/relatorio-semestral-agosto-2022/
• 2022年3月以降に27億回以上、直近の4週間では8億回の
APIコールを実行
• API連携の同意確認数は670万件以上
• 参加機関ディレクトリに登録された組織は800以上
• 参加コングロマリット150社（うち13社には参加義務）
• 複数の機関から1日あたり600人がOpen Financeに貢献

26. 26
• 2013年ブラジルにて創業。現在メキシコ・コロン
ビアにも進出
• モバイルアプリ前提の年会費無料クレジットカー
ドからスタートし、有効期限のないポイントプロ
グラム、維持費不要のデジタル口座、デビット
カード、個人向けローン、保険、ネット証券、決
済などに事業範囲を拡大
• 物理的な拠点を持たず、AIや顧客とのデジタル対
話を多用し、顧客満足度を重視した非常に身軽な
運営モデル
• 2022年Q2時点のブラジルの顧客数は6,530万人(成
人人口の1/3)、うち5,230万人がアクティブに利用
• 2021年度に黒字化
Nubank: 世界最大のデジタルバンク
Source: 日本総研 https://www.jri.co.jp/MediaLibrary/file/report/researchfocus/pdf/13154.pdf, HBS https://digital.hbs.edu/platform-digit/submission/nubank-building-a-usd-10-billion-fintech-in-6-years/,
Nubank https://api.mziq.com/mzfilemanager/v2/d/59a081d2-0d63-4bb5-b786-4c07ae26bc74/793c035c-9294-c868-bc21-167f5dd529d3?origin=1,

27. 27
• 内製化 (in-house)
– モバイルクレジットカードサービスをスク
ラッチから開発し、7カ月でローンチ
– “わたしたちはすべてのテクノロジーを内
製化しています。それが自身の競争優位性
のひとつだからです。”
• 正規性 (canonicity)
– 技術スタックをできるだけシンプルに維持
し、効率を高める
– 同時に、もしそれらのツールが理想的では
なかったり、より良い選択肢があったり、
全く役に立たなかったりした場合には、別
の解決方法を探る
• ときには言語の開発元を買収
– Cognitect社 (Clojure), Plataformatec社 (Elixir)
テック企業としてのNubank
Source: AWS https://aws.amazon.com/jp/solutions/case-studies/nubank/, Nubank https://building.nubank.com.br/nubank-culture-and-values/, https://building.nubank.com.br/the-value-of-canonicity/

28. 28
Nubankとオープンバンキング

29. 29
2017: Adapt
• 既存のインターネット
バンキングサービスに
API認可基盤を追加
• 参照系APIがターゲット
2019: Build
• スクラッチから構築する
デジタルバンキング基盤の
コアにAPI認可機能を包含
• 野心的なアーキテクチャ
2021: Evolve
• 参照系API基盤の老朽化を
契機とし、更新系APIに
耐えうる基盤への刷新
• 比較的大規模
国内のオープンAPI基盤整備の進展

30. 自社アプリ＆Fintech
企業向け銀行API基盤を
短期間に構築
30
• Azureを採用し、短期間・低コストな
オープンAPI基盤を構築
– 3カ月でAPIプラットフォームを構築
• AuthleteがAzureのAPI認可機能を代替
– セキュリティ強化のためのOAuth拡張
仕様に対応
– オンラインバンキングの既存認証シス
テムをそのまま活用
– FAPI等の新しい仕様にも将来的に対応
可能
セブン銀行
Azure PaaS
API Management
Web Apps Jobs
Push
Notification
Hub
App Services
HTTPS/JSON
Online
Banking
System
Ledger
System
Other Banks
SOAP/SFTP
on cloud

31. • 本人確認済みIDを発行する
認証認可基盤サービス
• API認可基盤にAuthleteを採
用しFAPI/CIBAを実装
SBI デジトラスト“Trust Idiom”
Source: NEC
https://wisdom.nec.com/ja/feature/digitalfinance/2021121001/index.html
FAPIとCIBAに準拠した
本人確認済みID発行 &
多要素認証基盤
31
金融 API を中核とする新サービスの展開にあたり、業界の標準仕様である
FAPI と CIBA の採用は必然と言えます。それら標準技術への迅速な対応、
自社サービス基盤への統合の容易性、そして OAuth 2.0 (OAuth) および
OpenID Connect (OIDC) の高い知見を評価し、Authlete を選択しました。
(SBIデジトラスト社 代表 バスケス・カオ・フェルナンド・ルイス氏)

32. モバイル向けAPI認可
基盤を構築。FAPI準拠の
オープンAPIへ拡張
• ゼロベースで設計された
次世代のデジタルバンク
• OAuth/FAPIの進化に適応
可能な基盤を構築
みんなの銀行
32
構築開始から 2 年弱でのサービスインを実現するというスケジュールの
下、 API セキュリティ機能は、預金や振込などの基本機能と共に、 最初の
MVP (Minimum Viable Product) に含まれていました。 与えられた開発期間
は約 7 ヶ月です。この中で、OAuth 2.0 をベースとする API 認可基盤と、
銀行としての勘定系システムを、同時に実装する必要がありました。
(株式会社みんなの銀行 デジタルサービスマネジメントグループ
稲倉直也氏）

33. 進化するアイデンティティアーキテクチャ

34. サービス事業者
2000s: 独立した「アイデンティティ基盤」
自社サービスとは別のやりかたで開発・運用。UIやAPIエンドポイントも独自のアーキテクチャに基づく
サービス基盤
サービス
サービス
サービス
サービス
サービス
サービス
APIゲート
ウェイ /
UI
ユーザー
APIクライアント
アイデンティティ基盤
• ユーザーインターフェイス
• APIエンドポイント
• アイデンティティデータと
ビジネスロジック
• …
34

35. 2010s: 「アイデンティティ基盤」のクラウド
運用の手間は軽減されたものの、これまで以上に別個の基盤となり、自社サービスとの調和を取るのがますます困難に
サービス事業者
サービス基盤
ユーザー
APIクライアント
APIゲート
ウェイ /
UI
IDaaS
• ユーザーインターフェイス
• API エンドポイント
• アイデンティティデータと
ビジネスロジック
• …
サービス
サービス
サービス
サービス
サービス
サービス
35

36. サービス事業者
サービス基盤
サービス
2020s: アイデンティティサービスの内包化
アイデンティティを基盤ではなく自社サービスとして位置づけ、他のサービスと同様、自分自身で完全にコントロールする
APIゲート
ウェイ /
UI
サービス
サービス
サービス
サービス
サービス
アイデンティティサービス
アイデン
ティティ
データ
ビジネス
ロジック
ユーザー
認証
OAuth/OIDC
プロトコル
処理
トークンライフ
サイ クル管理
同意管理 権限管理 …
ユーザー
APIクライアント
36

37. サービス事業者
サービス基盤
サービス
サービス
サービス
サービス
サービス
APIゲート
ウェイ /
UI
アイデンティティ部品のサービス化
アイデンティティサービスの構成要素をWeb APIとして提供する“Identity Component as a Service (ICaaS)” の登場
アイデンティティ
コンポーネント
API
API
API
API
API
API
ユーザー認証
…
OAuth/OIDC
プロトコル処理
同意管理
権限管理
トークンライフ
サイクル管理
ユーザー
APIクライアント
アイデンティティサービス
アイデン
ティティ
データ
ビジネス
ロジック
ユーザー
認証
OAuth/OIDC
プロトコル
処理
トークンライフ
サイ クル管理
同意管理 権限管理 …
アイデンティティサービス
アイデン
ティティ
データ
ビジネス
ロジック
ユーザー
認証
OAuth/OIDC
プロトコル
処理
トークンライフ
サイ クル管理
同意管理 権限管理 …
37

38. Authlete: OAuth/OIDC Component as a Service
KYC情報を
当人の同意に
基づき共有
更新系を含む
オープンAPI
の提供
業界標準の
API認可と
ID連携
自社アプリ
& Webサイト
Fintech
事業者
他社
サービス
OAuth 2.0 &
OpenID Connect
プロトコル処理
アクセストークン
ライフサイクル管理
OAuth 2.0 &
OpenID Connect
FAPI & CIBA
OIDC4IDA
OAuth 2.0 &
OpenID Connect
プロトコル処理
アクセストークン
ライフサイクル管理
最先端の業界標準API仕様に準拠
特定ソリューションに依存せず自由にUX設計が可能
OAuth 2.0 & OpenID Connect に関する複雑な実装・運用を外部化
サービス事業者
銀行・Fintech・メディア・SaaS・
ヘルスケア・エンタメ・ECなど
柔軟な開発・運用が可能
38

39. 金融サービスを中心に多数の事業者が採用
Awards
金融
KYC
システム・インテグレーション
B2B / B2E
教育
EC / 小売
*1 LINE Bank設立準備株式会社
ヘルスケア
IoT
NTT Docomo
Nubank
楽天銀行
LINE Bank *1
DPG Media
メディア
39
セブン&アイ

40. Authlete を活用した認可サーバーの構築
API認可・公開基盤
APIクライ
アント
既存システム
Webサイト
携帯端末
ネットワーク
デバイス
認可サーバー
認可ロジック
（認可判定）
ユーザー
認証
同意確認 権限管理
APIサーバー・ゲートウェイ
/data /function /transaction
Authlete
認可
バックエンド
API
トークン管理
データベース
OAuth/OIDCリクエスト
（トークン取得）
APIリクエスト
(トークン利用)
認可状態確認
（トークン検証など）
OAuth/OIDC処理リクエスト（プロトコル処理とトークン管理）
認可
フロント
エンド
ユーザー管理・
認証と認可
サーバーを分離
Authleteに依存せず自由に
認可ロジックを実装・配備
APIサーバーと
認可サーバーの
構築・運用を分離
OAuth/OIDCプロトコル処理
とトークン管理を外部化
/…
様々な言語向けの
Authlete API
ライブラリで開発
40

41. 認可リクエスト
認可レスポンス
トークン
リクエスト
トークン
レスポンス
API
リクエスト
API
レスポンス
ユーザー認証・
アクセス承認
エンド
ユーザー
ユーザー
エージェント
クライアント
OAuth/OIDC
サーバー
リソース
サーバー
Authlete と OAuth/OIDC サーバーの連携フロー
認可リクエストを
「そのまま」転送
エンドユーザーに
ひもづく認可コード
の発行を依頼
トークンリクエストを
「そのまま」転送
イントロス
ペクション
を依頼
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
41

42. まとめ

43. 43
• オープンAPIの提供状況と “Embedded Finance” が目指す
世界との間には依然としてギャップが存在
• 更新系APIに欠かせない “FAPI” とオフライン連携を実現
する “CIBA” に注目
• Nubankをはじめとする国内外の先進的な金融機関は
オープンバンキングに向けてシステムを確立
• アイデンティティアーキテクチャは “単一の基盤” から
“コンポーネントを活用したサービス” に進化
まとめ

44. Thank You
tatsuo.kudo@authlete.com
www.linkedin.com/in/tatsuokudo