Prepared for 「認証」について熱く語る！秋のLT大会（Around the Auth） https://majisemi.connpass.com/event/104808/ 今後の新たなユーザー認証体験のベースとなりうる OpenID Connect CIBA 仕様と、Authlete 社の取り組みについてご紹介します。

1. 「認証」について熱く語る！秋のLT大会 (Around the Auth) 2018-11-08
CIBAの可能性
工藤達雄

2. In This Talk
今後の新たなユーザー認証体験の
ベースとなりうる
OpenID Connect CIBA 仕様と
Authlete 社の取り組みについて
ご紹介します。

3. About Me
• 工藤達雄 https://www.linkedin.com/in/tatsuokudo
– サン・マイクロシステムズ (1998-2008)
– 野村総合研究所 (2008-2018)
– OpenIDファウンデーション・ジャパン(2013-2014)
– NRIセキュアテクノロジーズ (2014-2018)
– Authlete (2018-)
• VP of Solution Strategy

4. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス

5. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
1
1. ログイン開始

6. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
2
2. 認証・認可リクエスト

7. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
3
3. 「ログインしてください」

8. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
4 4. ID/パスワード
を送信

9. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
5
5. 認証結果・トークン

10. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
6
6. ログイン完了

11. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
API
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
ユーザー
デバイス
7
7. トークンを使ってAPIアクセス

12. Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
61 3 4
2
5
7
6. ログイン完了
API
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
2. 認証・認可リクエスト
3. 「ログインしてください」
4. ID/パスワード
を送信
5. 認証結果・トークン
7. トークンを使ってAPIアクセス
ユーザー
デバイス
1. ログイン開始

13. Decoupling AuthN from Consumption
ユーザー
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
デスクトップ

14. Decoupling AuthN from Consumption
ユーザー
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
デスクトップ
利用

15. Decoupling AuthN from Consumption
ユーザー
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
デスクトップ
利用
スマートフォン

16. Decoupling AuthN from Consumption
ユーザー
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
デスクトップ
利用
スマートフォン
認証・認可
リクエスト

17. Decoupling AuthN from Consumption
ユーザー
デスクトップ スマートフォン
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
利用 認証
認証・認可
リクエスト

18. ユーザー
スマートフォン
Consumption from Another Device
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）

19. ユーザー
スマートフォン
Consumption from Another Device
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
POS端末

20. ユーザー
スマートフォン
認証
Consumption from Another Device
POS端末
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
利用
認証・認可
リクエスト

21. ユーザー
スマートフォン
Consumption by Another User
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）

22. ユーザー
スマートフォン
Consumption by Another User
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
デスクトップ
オペレーター

23. ユーザー
スマートフォン
Consumption by Another User
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
利用 認証
デスクトップ
オペレーター
認証・認可
リクエスト

24. AuthN Initiated by Client via Backchannel
ユーザー
3. 認証結果・トークン
1. 対象ユーザーを指定して
認証・認可リクエスト
クライアント
（リライング・パーティ）
認可・APIサーバー
（アイデンティティ・プロバイダー）

25. CIBA (Client Initiated BackchannelAuthentication)
https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml
• OpenID Foundation (OIDF) が策定中の「認証フロー」の仕様
– 2017年5月 “OIDC MODRNA* CIBA Flow 1.0” 実装者向け草案が承認
• もともとはモバイル向け
– MODRNA WG にて策定が進められていた
• 現在、広範なユースケースに対応するための改良が進められている
– MODRNA WG と FAPI** WG** が連携
– “CIBA Core” と各種プロファイル (MODRNA, FAPI, …) の構成
(*) Mobile Operator Discovery, Registration & Authentication
(**) Financial-grade API

26. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント

27. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント
0
0. ユーザーの
識別子を把握
login_hint_token
id_token_hint
login_hint

28. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント
1
1. 認証
リクエスト
User Identifier

29. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント
2
2. 受付応答
AuthN Req ID

30. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント
2’
2’. ユーザー
認証

31. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント
3
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
ID Token / AT* / (RT**)

32. CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント
API
(4)
(4) トークン
を使ってAPI
アクセス
(4)
(4) 認証結果を
利用して処理を
実行

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

34. CIBA is Gaining Momentum 😎
Source: https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines.pdf, https://openbanking.atlassian.net/wiki/spaces/DZ/pages/642090641/Account+and+Transaction+API+Specification+-+v3.0,
https://www.recruit.net/job/security-architect_london_jobs/652C3F6C7260E6D3

35. Authlete: BaaS for API Authorization Service
https://www.authlete.com/
• BaaS (Backend as a Service)として
利用できるため導入・運用が容易
• OAuth 2.0 / OIDC関連仕様を網羅した
実装
• お客さまのフィードバックに基づき
仕様の先を行く機能群を実装
• 関連仕様の専門家集団が設計・運用
Grand Prize Winner

36. Solution Architecture
36
Authlete Customer’s EnvironmentAPI Clients
Existing Services
© 2018 Authlete, Inc.
Websites
Mobile
Networked
Devices
Authorization Server
Authorization Decision
User
Authentication
Consent
Management
Entitlement
Management
API Servers / Gateways
/data /function /transaction
Authlete
Authorization
BackendAPIs
Authorization
Information
(e.g. Tokens)
Database
Authorization Request
API Access
Authorization Status
Check
OAuth/OIDC Processing Request
Authorization
Frontend
Leveraging existing
services Authorization decision logic with no
dependency on Authlete
Separation of operation
between authorization
server and API servers
Externalizing cumbersome
OAuth/OIDC processing and
token management
/…
OSS components
available via GitHub

37. When it Comes to CIBA…
37
Authlete Customer’s EnvironmentClient
Existing Services
© 2018 Authlete, Inc.
Websites
Mobile
Networked
Devices
Authorization Server
Authorization Decision
User
Authentication
Consent
Management
Entitlement
Management
API Servers / Gateways
/data /function /transaction
Authlete
Authorization
BackendAPIs
Authorization
Information
(e.g. Tokens)
Database
Backchannel authn
API Access
Authorization Status
Check
OAuth/OIDC and CIBA Processing Request
/…
Token
Authorization
Frontend
Authentication
Device
Mobile
Not ification for user authn

38. まとめ
• デバイスを「サービス利用」と「ユーザー認証」に分離
することによりユーザー認証体験の可能性が広がる
• 「モバイル」と「金融API」の両分野がCIBAの標準化を
進めている
• Authlete は CIBA をサポートします（予定）
– そしてFIDO / WebAuthn ソリューションとの連携も…（願望）

39. Thanks!