Prepared for MyData Japan 2019 https://mydatajapan.org/events/mydata-japan-2019.html

1. 2019-05-15MyDataJapan2019
OAuth / OpenID Connect (OIDC) の最新動向と
Authlete のソリューション
工藤達雄
Authlete, Inc.

2. Agenda
• OAuth / OIDC の動向
• Authlete のソリューション
2

3. OAuth / OIDC の動向
3

4. アプリケーションにログインしてサービスを利用
4
ユーザー ユーザー・エージェント アプリケーション
ログインして
サービスを利用
ユーザー認証
ログイン
処理
データ・機能
サービス
処理

5. 外部の「ユーザー認証」や「ユーザーにかかる
データ・機能」と連携
5
ユーザー ユーザー・エージェント
データ・機能
ユーザー認証
ユーザー認証
アクセス許諾確認
アプリケーション
ログインして
サービスを利用
「認可
リクエスト」
「認証
リクエスト」

6. 実サービスにおける連携例
6
ユーザー ユーザー・エージェント アプリケーション
ユーザー認証
データ・機能
ログインして
サービスを利用
ユーザー認証
「認可
リクエスト」
「認証
リクエスト」
アクセス許諾確認
Source: マネーフォワード, Google, 三井住友銀行
ユーザー認証
ユーザーにかかるデータ・機能

7. オープン標準: OIDCとOAuth
7
ユーザー ユーザー・エージェント アプリケーション
アイデンティティ・
プロバイダ
認可サーバー・
リソースサーバー
ログインして
サービスを利用
ユーザー認証
「認可
リクエスト」
「認証
リクエスト」
アクセス許諾確認

8. 8
• 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 / 旧 OpenID Connect → AB/Connect
• 2012: OAuth 2.0 仕様化
• 2014: OpenID Connect 1.0 仕様化
• … この後は!?
OAuth / OIDC のなりたち
Source: https://www.slideshare.net/tkudo/openid-connect-dev lov e

9. 現在も活発に拡張仕様・周辺仕様の策定が続いている
9Source: https://twitter.com/blhjelm/status/1055551254401736704

10. 10
• FAPI + CIBA
• OAuth 2.0 Security BCP
• OAuth 2.0 for Browser-BasedApps BCP
• JWT Profile for Access Token
• OAuth in a Kubernetes Environment
• Authentication and Authorization for Constrained Environments (ACE) using
the OAuth 2.0 Framework
• OAuth 2.0 Demonstration of Proof-of-Possessionat the Application Layer
• …
主なトピックス @ OAuth Security Workshop 2019
https://www.slideshare.net/tkudo/osw2019
Source: https://sec.uni-stuttgart.de/events/osw2019

11. FAPI
11

12. Financial-grade API (FAPI)https://openid.net/wg/fapi/
• 金融サービスのAPIに対応したOAuth適用規定と
周辺仕様
• OpenID FoundationのFAPI WGにて現在策定中
– セキュリティ・プロファイル:実装者向け草案
• Read Only API Security Profile, Read & Write API
Security Profile
– 周辺仕様: ワーキングドラフト & 実装者向け草案
• JARM, CIBA
– API:今後策定予定
• Open Data API, Read Only API, Read & Write API
12
Source: https://openid.net/wg/fapi/

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

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

15. FAPI 採用の動向
• UK Open Banking
https://www.openbanking.org.uk/
• Australian Consumer Data Right (CDR)
https://github.com/ConsumerDataStandardsAustralia/infosec
• Slovak Banking API Standard
https://www.sbaonline.sk/Content/files/projects/slovak-banking-api-standard-1_1.pdf
• MKB Bank (ハンガリー)
https://portal.sandbox.mkb.hu/api-documentation/account-info-1.0
• Payments NZ API standards
https://paymentsdirection.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/overview
15

16. UK Open Banking
https://www.openbanking.org.uk/
• 英国における「銀行API」の共通仕様
– 2018年1月開始
– 大手9行は義務化により、それ以外の銀
行は自発的に採用
– 2019年3月時点で、銀行40社、サード
パーティ事業者78社が参加
• 「セキュリティ・プロファイル」の
ベースとしてFAPI Part 2 を採用
16Source: https://www.openbanking.org.uk/about-us/news/open-banking-march-highlights/, https://www.w3.org/2018/Talks/cm-openbank-20181022.pptx
Version 3 Technical Specifications
Introduction
Open Data APIs
• ATM info
• Branch info
• Product info
• Personal Current Accounts
• Business Current Accounts
• SME Lending
• SME Credit Cards
Read / Write APIs
• Account & Transaction Info (‘read’)
• Payment Initiation (‘write’)
• CBPII (‘funds check’)
• Event (‘notifications’)
New in Version 3, launched Sept 2018:
• Covers Redirect and Decoupled Flows
• All payment accounts (incl. credit cards,
wallets, pre-paid)
• Domestic and international payments
• Multi-currency
• Single Immediate, Scheduled, File
Payments
• Confirmation of Funds
Security Profile
• FAPI Profile (redirect)
• CIBA Profile (decoupled)
• Dynamic Client Management
(onboarding)
• Based on OAuth2 and OIDC
• MTLS
• JWS
© Open Banking Limited 2018 3

17. 日本国内でもFAPIを推奨する動き
17Source: https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf Source: https://www.paymentsjapan.or.jp/news/20190330_api_guidelines/

18. CIBA
18

19. 19
“Redirect Flow”
Source: マネーフォワード, Google
ユーザー ユーザー・エージェント
1. 「外部サイトで
ログイン」
2. リダイレクト 4. リダイレクト 3. 認証

20. “Decoupled Flow”
• 「アレクサ、お店に
5,000円払って」
→ 手元のケータイに
決済サービスAppから
通知
20Source: https://www.europeanpay mentscouncil.eu/document-library /minutes-and-agendas/authentication-sca-guidance-key -topic-clarif ication-api

21. “Decoupled Flow”
• TVショッピングとかで、
– 視聴者が電話で購入希望を伝える
– オペレーターに「ではお客さまのスマート
フォンに注文内容をお送りします。ご確認
をお願いします」と言われる
– 視聴者は手元のスマートフォンにきた、決
済サービスAppからの通知をみて承認する
21Source: https://www.linkedin.com/pulse/decoupled-authentication-moto-tatsuo-kudo/

22. “Decoupled Flow”
• 仮に Ponta の ID と決済できるとこのIDが
紐づいてたら
– コンビニ店員「Pontaカードカモン」
– 客「はい」
– 店員「XXX円です」
– 客「CIBAPay(ﾀﾞｯｻ)」
– 店員「はい(ﾎﾟﾁ)」
– 客のスマホ「(XXX円をローソンに支払います。
よろしいですか？)」
– 客「おk」
– 店員「支払いおわた。レシートどぞ」
ぐらいは出来そうです
22Source: https://ritou.hatenablog.com/entry /2018/12/29/224452

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

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

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

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

27. • OpenID Foundation (OIDF) が策定中の「認証フロー」の仕様
– 2017年5月 “OIDC MODRNA* CIBA Flow 1.0” 実装者向け草案が承
認
• もともとはモバイル向けだったが、現在は広範なユースケー
スに対応するための改良が進められている
– MODRNA WG と FAPI WG が連携
– “CIBA Core” と各種プロファイル (MODRNA, FAPI, …) の構成
• 2019-02-04 に CIBA Core Implementer’s Draft が承認
CIBA (Client Initiated BackchannelAuthentication)
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
(*) Mobile Operator Discovery, Registration & Authentication

28. CIBA Flow
ユーザー
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
Identif ier
2
2. 受付応答
AuthN Req ID
3
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
ID Token / AT* / (RT**)
バックチャネル認証
エンドポイント
2’
2’. ユーザー
認証

29. Authlete のソリューション

30. 30
“OAuth 2.0” の基本的なシーケンス
(AuthorizationCode GrantFlow / Bearer Token)
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
（完了）
ユーザー認証・
アクセス承認
認可
リクエスト
認可
コード
認可
コード
アクセス
トークン
アクセス
トークン
APIレスポンス
• 認可リクエストを受け付けたら
認可コードを返す
• 認可コードをもらったら
アクセストークンを返す
• アクセストークンつきの
APIリクエストを受け付けて
レスポンスを返す

31. シーケンスは単純だがサーバー側の処理は複雑
31
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
認可リクエストの処理
・指定されているパラメーターは適切か?
・クライアント、スコープ、リダイレクトURIの組み合わせは正しいか?
・エラーの場合にはどのようなレスポンスを返すべきか?
認可コードとトークンの生成
・アクセストークンにどのような情報をひもづけるか?
・認可レスポンスをどのような形式にして送信するか?
・ユーザーがキャンセルした場合にはどのようなレスポンスを返すべきか?
トークンリクエストの処理
・指定されているパラメーターは適切か?
・クライアントをどのように認証するか?
・エラーの場合にはどのようなレスポンスを返すべきか?
アクセストークンの検証
・アクセストークンは利用可能か（失効していないか）?
・アクセストークンにひもづく情報をどう取得するか?
・エラーの場合にはどのようなレスポンスを返すべきか?

32. 32
Authlete: サーバー側の複雑な処理を代行するAPI
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
（スタート）
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
Authlete API
認可リクエスト
処理
認可コードと
トークン生成
トークンリクエスト
処理
アクセス
トークン
検証

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

34. FAPI / CIBA をサポート
34
FAPIサポート (2018-07-24)
• UK Open Banking Security Profile
Conformance に掲載 *
CIBAサポート (2019-02-13)
• CIBA テストスイートのベータ版をクリア
した世界初のソリューション **
* https://openbanking.atlassian.net/wiki/spaces/DZ/pages/126321042/Open+Banking+Security +Prof ile+Conf ormance
** Source: f intechlabs.io 社（英国の Open Banking において FAPI および CIBA のテストスイートを開発）

35. 35
• OpenID Foundation が2019年4月から開始した Financial-grade API
Certification プログラムにおいて、Authlete が当該 Certification を取得
• 2019年5月15日現在、Mutual TLS および Private Key の両クライアン
ト認証方式での認定を取得しているのは Authlete のみ
OpenID Foundation の FAPI 認定を最速取得
Source: https://openid.net/certif ication/

36. 多数の利用実績。有力企業様も活用
36
採用実績例
コンシューマーIAMソリューション
「Uni-ID Libra」の認可エンジンとして採用
ユーザープロファイル（地域別）
Grand Prize Winner
ヘルスケアサービス「ルナルナ」等で採用
API 公開基盤「Resonatex」 に採用
銀行APIの認可基盤として採用
各種サービスの認可サーバとして採用
IBM 賞
受賞歴
49%
21%
14%
12% 3% 1% Japan
North America
Europe
Asia
IoTプラットフォームにて採用
銀行APIの認可基盤として採用

37. 37
2019-05-14プレスリリース https://www.authlete.com/ja/news/20190514_mdi/
株式会社マイデータ・インテリジェンスさま
MEY活用企業
個人情報に関するリスク・コストを
抑えつつ、マーケティングを実施
MEY利用者
自身の個人情報をコントロール
しつつ、便利な暮らしを実現
認可処理を委託
情報銀行サービス
• 短期間でのサービスインを実現
• 標準仕様に準拠したセキュアな ID 連携
• 最新の仕様に追随

38. まとめ

39. まとめ
• OAuth/OIDC
– 現在も活発に仕様策定が進行中
– その中でも FAPI と CIBA に要注目
• Authlete
– FAPI/CIBAにも対応可能なOAuth/OIDC基盤
を、シンプルかつセキュアに実現します
39

40. Thank You
www.authlete.com
www.linkedin.com/in/tatsuokudo