Prepared for Google Cloud INSIDE FinTech https://inthecloud.withgoogle.com/fintech-jp-02-19/register.html Authlete は、OAuth 2.0 / OpenID Connect サーバーを「正しく」実装するための API サービスです。金融 API の標準と目される Financial-grade API (FAPI) と、Google Apigee と Authlete の連携による FAPI 対応、そして SaaS 事業者としての弊社の Google Cloud 活用についてご紹介します。

1. #gc_inside

2. 工藤達雄
Authlete: セキュアな金融 API 基盤の実現と
Google Cloud の活用
Authlete

3. About Me
● サン・マイクロシステムズ、野村総合研究所、NRI セ
キュアを経て、2018年から Authlete 社にて VP of
Solution Strategy を担当
● 専門はデジタル・アイデンティティを中心とするプリ
セールス、コンサルティング、事業開発、
エバンジェリズム
● LinkedIn https://www.linkedin.com/in/tatsuokudo
Twitter @tkudos

4. Who is Authlete?
API セキュリティの “B2D”
(Business-to-Developer) SaaS
プロバイダー
2015/09 🔵 Authlete 社設立
2016/09 🔵 Authlete UK 設立
2016/11 🔵 FINOLAB に入居
2017/03 🔵 FIBC 2017 大賞受賞
2017/05 🔵 Level39 に入居
2017/05 🔵 資金調達（シード）
2017/07 🔵 OpenID Certification 取得
2017/09 🔵 Tech in Asia Tokyo 2017 決勝
2018/02 🔵 資金調達（プレシリーズA）
2018/04 🔵 Draper Nexus B2B Summit 2018 にて IBM 賞受賞
2018/07 🔵 Japan/UK Open Banking and APIs Summit 2018 開催
2018/07 🔵 Financial-grade API (FAPI) サポート
2018/08 🔵 Open Banking Security Profile テスト合格
2019/01 🔵 『OAuth 徹底入門』 監修
2019/02 🔵 CIBA サポート
2019/04 🔵 OpenID FAPI Certification 取得
2019/09 🔵 OpenID FAPI-CIBA OP Certification 取得

5. Agenda
● Authlete + GCP による「金融グレード API」の実現
● Authlete サービスにおける GCP 活用

6. Authlete + GCP による
「金融グレード API」の実現

7. OAuth: トークンによるアクセス権移譲
ユーザー
認証・同意確認
当人確認と同意確認を直
接行うことができる
（ID/PW,モバイルApp, 専用デバイス、 …）
銀行
「アクセストークン」を用いたAPIアクセス
Fintech
事業者
利用
銀行のログイン情報を渡
さずに利用できる
✔ 口座情報
✔ 送金機能
✔ 与信情報
✔ 口座一括管理
✔ 入金・送金
✔ 決済
API公開
⇒ 売上・集客拡大
API利用
⇒ 新サービス創出
ユーザーに関する口座情報や決
済機能を活用できる
✔ 複数口座をまとめて
管理したい
✔ 振込処理をかんたん
にしたい
✔ 銀行口座を決済に使
いたい

8. “OAuth Dance”
利用者 Fintech 企業 金融機関
ユーザー Web ブラウザ Web サイト
認可
サーバー
API サーバー
認可
リクエスト
認可
コード
認可
コード アクセス
トークン
アクセス
トークン
API レスポンス
ログインして連携
を許可
金融機関との連
携を開始
連携完了

9. OAuth / OpenID Connect (OIDC) の標準化状況
Source: https://twitter.com/blhjelm/status/1055551254401736704
● 2005~2007: 黎明期
○ 2005: OpenID 誕生 / 2006: OAuth 誕生
● 2007: OpenID 2.0 / OAuth 1.0 仕様化
● 2008~2012: 変革期
○ OAuth 1.0 → 1.0a → WRAP
○ OpenID 2.0 → Contract Exchange / Artifact Binding (AB) / 旧 OpenID Connect
→ AB/Connect
● 2012: OAuth 2.0 仕様化 / 2014: OpenID Connect (OIDC) 1.0 仕様化
● …
● 2019: 引き続き活発に仕様策定が続いている

10. 金融 API に OAuth/OIDC をどう使うか
● OAuth 仕様の解釈のブレや実装の不備が頻発
● 金融機関が個別に OAuth を適用し、対策水準も各社各様
● 結果的に…
○ 金融機関（API 提供事業者）が「オープン標準ではない独自仕様」かつ
「不十分なセキュリティ対策」をサードパーティ（API 利用事業者）に押し
付ける構図
○ サードパーティによる API 活用の阻害要因に

11. Financial-grade API (FAPI)
● 金融 API 向けの OAuth 2.0 適用プラクティス
● さまざまな立場の専門家が仕様策定に集結
○ OAuth / OpenID Connect 仕様策定者
○ 金融機関
○ サードパーティ（Fintech 事業者）
○ セキュリティ研究者
○ ソリューションベンダー
○ …
Source: https://openid.net/wg/fapi/

12. FAPI セキュリティ・プロファイル
● Part 1 (Read Only)
○ OAuth 2.0 適用プラクティス+ 拡張仕様
○ OIDC によるユーザー識別子の授受
● Part 2 (Read & Write)
○ OIDC の積極的な活用+ 新たな拡張仕様
○ Request Object, Hybrid Flow, MTLS,
OAUTB
○ JARM
OIDC 拡張仕様
OIDC プラクティス
OAuth2 拡張仕様
OAuth2 プラクティス
Part1(ReadOnly)
Part2(Read&Write)

13. “OAuth Dance” の改善・改良
● 認可リクエスト / レスポンスの送信者詐称
・改ざん防止
○ Request Object の利用
○ Hybrid Flow もしくは JARM の利用
● 認可コードの漏洩・盗用防止
○ redirect_uri の厳密な管理
● クライアントのなりすまし防止
○ Mutual TLS もしくは JWT によるクライアント認証
● トークンの漏洩・盗用防止
○ OAUTB（トークン・バインディング）もしくはMTLS（双
方向 TLS 接続へのバインド）の利用
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
（完了）
ユーザー認証・
アクセス承認
認可
リクエスト
認可
コード
認可
コード
アクセス
トークン
アクセス
トークン
API レスポンス

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

15. CIBA Client Initiated Backchannel Authentication
● 「サービスを利用するデバイス」と「認証を行うデバイス」を分離
(decouple) し、API の適用シーンを拡大

16. CIBA のフロー
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・パー
ティ）
認可・API サーバー
（アイデンティティ・プロバ
イダー）
0
0. ユーザーの
識別子を把握
login_hint_token
id_token_hint
login_hint
BA EP
API
(*) Access Token
(**) Refresh Token
(4)
(4) トークンを
使って APIアク
セス
(4)
(4) 認証結果を利
用して処理を実
行
1
1. 認証
リクエスト
User
Identifier
2
2. 受付応答
AuthN Req ID
3
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
ID Token / AT* / (RT**)
バックチャネル認証エ
ンドポイント
2’
2’. ユーザー
認証

17. FAPI が求める OAuth/OIDC 実装
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
認可リクエスト処理
・Request Object
認可コード発行
・OIDC Hybrid Flow / JARM
トークンリクエスト処理
・Client Authentication w/ MTLS
・Sender-constrained Token
アクセストークン検証
・Client Authentication w/ MTLS
・Sender-constrained Token
・Token Introspection

18. 複雑な処理を Authlete が代行
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
Authlete API
認可リクエスト処
理
認可コード生成
トークンリクエスト処理
アクセス
トークン検
証
認可サーバーと
リソースサーバーに
おける複雑な処理を
Authlete に外部化
→ 開発者の負担を軽減し
開発期間の短縮と
セキュリティリスクの
低減に貢献

19. Authlete による認可リクエスト処理の例
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
Authlete API
認可リクエスト処
理
Authlete
GET /authorize
?redirect_uri=https://client.example.org
/cb/example.com
&response_type=code
&client_id=12800697055611
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t
8URWbuGJSstw-cM
&code_challenge_method=S256 HTTP/1.1
Host: as.example.com
「認可エンドポイント」が
認可リクエストを受信
リクエストの内容を
そのまま Authlete に転送
/auth/authorizationPOST
{"parameters":"redirect_uri=https://client.
example.org/cb/example.com
&response_type=code&client_id=12800697055611
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t
8URWbuGJSstw-cM
&code_challenge_method=S256"}

20. Authlete を活用した認可サーバーの構築
API 認可・公開基盤
API
クライ
アント
既存システム
Web サイト
携帯端末
ネットワーク
デバイス
認可サーバー
認可ロジック
（認可判定）
ユーザー
認証
同意確認 権限管理
API サーバー
/data /function /transaction
Authlete
認可
バックエ
ンド
API 認可情報
DB
API 認可リクエスト
（トークン取得）
API アクセス
(トークン利用)
認可状態確認
（トークン検証など）
OAuth/OIDC 処理リクエスト（認可コード/トークン発行など）
認可
フロントエン
ド
既存の認証/同意/
権限等と認可
サーバーとを分離
Authlete に依存することなく
自由に認可ロジックを実装可能
API サーバーと
認可サーバーの
構築・運用を分離
面倒な OAuth/OIDC 処理
と認可情報（トークン）
管理を外部化
/…
認可サーバー
構築に必要な
ライブラリを
OSSにて提供

21. バックエンドAPI 管理基盤
Apigee
リクエスト
Apigee + Authlete for FAPI Deployment
既存システム
認可ロジック
（認可判定）
ユーザー
認証
同意確認 権限管理
Authlete
認可
バックエ
ンド
API
認可情報
DB
API 認可リクエスト
（トークン取得）
API アクセス
(トークン利用)
認可状態確認（トークン検証など）
OAuth/OIDC 処理リクエスト（認可コード/トークン発行など）
OAuth
エンド
ポイント
API
エンド
ポイント
API
クライ
アント
Web サイト
● Request Object
● Hybrid Flow / JARM
● Client Authentication
w/ MTLS
● Sender-constrained
Token
● Client Authentication
w/ MTLS
● Sender-constrained
Token

22. Request Object
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
OIDC 認証リクエスト
• 値渡し
• 参照渡し
リクエストオブジェクトのクレーム
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb",
"scope": "openid",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"max_age": 86400,
"claims":
{
"userinfo": { … "email": {"essential": true},…},
"id_token": { "gender": null, …
"acr": {"values":
["urn:mace:incommon:iap:silver"]}
}
}
}
GET /authorize? request=eyJhbGciOiJSUzI1NiIsImtpZCI6Imsy
YmRjIn0.ew0KICJpc3MiOiAiczZCaGRS…
GET /authorize?
request_uri=%3A%2F%2Fclient.example.org%2Frequest.jwt…
リクエストオブジェクト生成
OIDC 認証リクエストへの署名や暗号化
（スタート）
(OIDC) 認証リクエスト
(OIDC) 認証レスポンス
トークン
リクエスト
トークン
レスポンス
API
リクエスト
ユーザー認証・
アクセス承認

23. Sender-Constrained Token (mTLS)
トークンリクエスト時のクライアント証明書にアクセストークンをバインド
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
トークンリクエスト
• TLS相互認証を行ってクライアントのX.509証明書を取得し、
その証明書のサブジェクトDNをもとにクライアントを認証
• リクエスト内のclient_idの値からクライアントを識別
• そのクライアント情報として事前登録されている「証明書の
サブジェクトDN」の値と照合し認証
X.509 PKC +
code + client_id
client_id
code
トークンレスポンス
• 証明書に結びつけた（バインドした）アクセストークンを返却
AT, RT
APIリクエスト
• TLS相互認証を行いクライアントのX.509証明書を取得
• 証明書とアクセストークンの結びつき（バインド）を確認
• トークンに含まれる or イントロスペクションの結果として得ら
れる、証明書の「サムプリント」を利用
X.509 PKC + AT
X.509 PKC +
RT + client_id
（スタート）
(OAuth) 認可
リクエスト
(OAuth) 認可
レスポンス
トークン
リクエスト
トークン
レスポンス
API
リクエスト
ユーザー認証・
アクセス承認

24. Authlete サービスにおける
GCP 活用

25. Our Offerings
● お客さまの要件に応じてマ
ネージドクラウド/オンプレミ
スにてサービスを提供
● マネージドクラウドの基盤と
して GCP を活用

26. Deployment Architecture
Kubernetes Engine
Logging
API Server Cloud SQL
Cloud SQL Instance
Stackdriver Logging
Cloud SQL
Proxy
Consoles
Cache Server 各種通知システム

27. GCP 複数リージョンの活用
https://www.authlete.com/ja/news/20191024_failover/
● Authlete サービスの
フェイルオーバー
○ 主リージョンの Authlete サー
バー障害時に副リージョンの
サーバーが応答
○ サーバーの切り替えを
自動的に実施
Region A Region B
Periodic replication
Health check
Switch traffic when region A down

28. GCP の良いところ
● 楽しい・使いやすい・新技術をいちばん早く試せる
○ コンテナ技術がいちばん進んでいる
○ コンソール / CLI が使いやすい * Stackdriver 以外
● GKE
○ 非常に安定している。またマネージドサービスであるため運用負荷を大幅に軽減
○ PaaS (GAE) に比べコントロールできる部分が多く、障害発生時も対処しやすい
● Cloud SQL
○ フェイルオーバーのしくみをかんたんに使える

29. GCP に期待するところ
● Stackdriver
○ 使い勝手の向上（とくにモニタリング）、ログ表示の応答性
● Cloud SQL
○ 東京・大阪リージョン間でのフェイルオーバー機能
○ メンテナンスやスケールアップ時のダウンタイム最小化
● GKE
○ ノードの面倒を見てくれるサービス（細かいところは任せたい）
● 全般
○ ステータス公開の強化（コミュニティ情報のほうが早くて正確なことも …）

30. Takeaways

31. まとめ
● Financial-grade API (FAPI)
○ 金融 API 向けの OAuth 2.0 / OpenID Connect 仕様
○ セキュリティ強化に有用だが実装には深い理解が必要
● Apigee + Authlete
○ FAPI 処理を Authlete に外部化し実装・運用を容易に
● Authlete on GCP
○ マネージドクラウドサービス提供の基盤として活用

32. リソース
● Authlete ウェブサイト
○ https://www.authlete.com/ja/, https://github.com/authlete
● OAuth/OIDC 解説記事・スライド
○ https://qiita.com/TakahikoKawasaki
○ https://www.slideshare.net/tkudo
● 弊社主催勉強会サイト
○ https://authlete.connpass.com/

33. Thank you