More Related Content
Similar to OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ その新しいUXと実装例のご紹介 - OpenID Summit 2020 (20)
More from OpenID Foundation Japan (20)
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ その新しいUXと実装例のご紹介 - OpenID Summit 2020
- 1. OpenID Connect Client Initiated
Backchannel Authentication Flow
(CIBA)のご紹介
~ その新しいUXと実装例のご紹介
2020年1月24日
NRIセキュアテクノロジーズ株式会社
ソフトウェアビジネス一部
- 2. 1
自己紹介
柴田 健久(Takehisa Shibata)
2000年 株式会社野村総合研究所 入社
2008年 デジタルアイデンティティ事業(後のUni-ID事業)の企画に参加
以来、同事業の企画推進
2014年 デジタルアイデンティティ事業移管とともにNRIセキュアテクノロジーズに出向
現在 NRIセキュアテクノロジーズ㈱ ソフトウェアビジネス一部長
OpenID Foundation 企業理事
情報処理学会 情報規格調査会 SC 27 WG5国内委員
赤星 拓未(Takumi Akahoshi)
2011年 野村総合研究所入社
Uni-ID事業の開発・SI・コンサルティングに従事
2014年 デジタルアイデンティティ事業移管とともにNRIセキュアテクノロジーズに出向
現在 同社CIAMプロダクト「Uni-ID Libra」 開発リーダー。
- 18. 17
③バックチャネル認証リクエスト
RPはユーザを特定するための3種類のヒントのうち一つのみをOPに送ります
エンドポイント POST /api/ciba/1.0/authorize
パラメータ 必須 説明 値の例 備考
scope 必須 oepnid profile OAuth2.0で定義されたscope
acr_values 任意 略 OIDC Coreで定義されたacr_values
client_notification
_token
モードに
よって
必須
RPが提供するBearトークン
8d67dc78-7faa-
4d41-aabd-
67707b374255
Pingモード、Pushモードの際に、OPがRP
に対してコールバックする際のクライアント認
証手段として利用
login_hint_token
いずれ
か一つ
必須
認証するユーザーを特定する
ためのヒント
(いずれか一つのみ送信)
認証対象ユーザーを特定する情報を含む
トークン(フォーマットは定義されていない)
id_token_hint eyJ(略) 過去RPに対して発行されたIDトークン
login_hint
例:メールアドレス、sub、
usernameなどが含まれる
認証対象ユーザーを特定する何らかの文字
列
binding_message 任意
CDとADで両方表示されるト
ランザクション認証メッセージ
例:W4SCT
比較的短いプレーンテキスト文字が推奨さ
れている
user_code 任意
OPとユーザーのみが知る
secret
例:PINやPW
ユーザーのADに対して本当に認証要求を
行ってよいか認証するためのコード
requested_expiry 任意
OPから返却されるauth_
req_idの有効期限(秒)
600
RP側が認証要求の有効期限を指定したい
場合
※クライアント認証に必要なパラメータは省略
※Uni-ID LibraにおけるBackchannel Authentication Endpoint API仕様を例に説明
- 19. 18
③バックチャネル認証リクエスト
RPはユーザを特定するための3種類のヒントのうち一つのみをOPに送ります
エンドポイント POST /api/ciba/1.0/authorize
パラメータ 必須 説明 値の例 備考
scope 必須 oepnid profile OAuth2.0で定義されたscope
acr_values 任意 略 OIDC Coreで定義されたacr_values
client_notification
_token
モードに
よって
必須
RPが提供するBearトークン
8d67dc78-7faa-
4d41-aabd-
67707b374255
Pingモード、Pushモードの際に、OPがRP
に対してコールバックする際のクライアント認
証手段として利用
login_hint_token
いずれ
か一つ
必須
認証するユーザーを特定する
ためのヒント
(いずれか一つのみ送信)
認証対象ユーザーを特定する情報を含む
トークン(フォーマットは定義されていない)
id_token_hint eyJ(略) 過去RPに対して発行されたIDトークン
login_hint
例:メールアドレス、sub、
usernameなどが含まれる
認証対象ユーザーを特定する何らかの文字
列
binding_message 任意
CDとADで両方表示されるト
ランザクション認証メッセージ
例:W4SCT
比較的短いプレーンテキスト文字が推奨さ
れている
user_code 任意
OPとユーザーのみが知る
secret
例:PINやPW
ユーザーのADに対して本当に認証要求を
行ってよいか認証するためのコード
requested_expiry 任意
OPから返却されるauth_
req_idの有効期限(秒)
600
RP側が認証要求の有効期限を指定したい
場合
※クライアント認証に必要なパラメータは省略
※Uni-ID LibraにおけるBackchannel Authentication Endpoint API仕様を例に説明
②id_token_hint:
RPが過去受け取ったIDトー
クン(をOPに返す)
③login_hint:
ユーザ特定できる文字列(メ
アド、username等)
①login_hint_token:
ユーザ特定する何らかのトー
クン(未定義)
binding_message:
一連のトランザクションであることをユーザに認識させるテキスト
CDで表示したテキストをOP経由で送り、ADに表示させる
user_code:
CDからADにいたずらに認証要求を行えてしまうの
を防ぐためのシークレット情報(PINなど)
- 23. 22
(CIBA仕様外)認証デバイスにプッシュ通知後、FIDO
UAFで認証を行った後同意を取るように実装
Uni-ID Libra
Firebase CM
Sample OP
バックチャネル
認証EP
トークンEP
プッシュ通知
FIDO RP
同意結果
通知EP
POST https://fcm.googleapis.com/fcm/send
{"data":
"title":"お支払い金額の確認",
"body":"NRI SHOPで20,000円のお買い物を許可しますか?",
"callback":”【同意結果通知EPのURL】+hash(auth_req_id)”,
"to":“{通知先のトークン}”
}
+binding_message
POST /callback/{hash(auth_req_id)}
“approved” : true
“acr” : “fidouaf”
①プッシュ通知要求
②プッシュ通知
③UAFによる認証
④同意結果通知
- 26. 25
デモ内容解説3/3
⑨⑩⑪トークンリクエストは3パターンあります
AD(認証デバイス)上でユーザの認証・同意が終わったことをRPが知る方法は3種類
ある。クライアント登録時にどのモードにするか1つのみ決める必要あり
モード Poll Ping Push
概要
RPはトークンエンドポイントに対して
ポーリング(定期的にリクエスト)を行う
AD上でユーザ同意が完了した後にリク
エストを行うと、トークンが返却される
AD上でユーザの同意が完了すると、
OPはRPに対して、完了通知を送る
通知を受け取ったRPはトークンリクエ
ストを行う
AD上でユーザの同意が完了すると、
OPはRPに対してトークンを返却する
イメージ
実装ポイント
• 既存のトークンエンドポイントの拡張
なので比較的楽に実装できる
• 複数RPがいる場合に性能考慮が必
要になるかも?
• →エラーレスポンス:slow_down
(ポーリング間隔5秒増やして)等が
定義されている
• 既存のトークンエンドポイントの拡張
なので比較的楽に実装できる
• OPは、RPがPollもできるように実
装しないといけない。→ならPollさえ
サポートしていればいい気もする
• 完了通知のリトライ処理等、仕様外
での考慮が必要
• あまりオススメしません。唯一既存の
トークンリクエストと向きが逆になる
のでセキュリティ考慮が必要
• サポートするなら、OPはIDトークン内
にもauth_req_idを埋めて、RPは
一連の要求であることをチェックさせな
いといけない
RP OP
POST /token
まだ終わってないよ
終わったからtokenあげる
POST /token
RP OP終わったよ
POST /token
RP OP
token
tokenあげる
(OK)
(OK)
後述
- 27. 26
トークンエンドポイント
通常のトークンエンドポイントに認可コードの代わりに受付番号を渡す
エンドポイント POST /token
パラメータ 必須 説明 値の例 備考
grant_type 必須 固定値 urn:openid:params:grant-type:ciba
auth_req_id 必須
バックチャネル認証要求でレス
ポンスされたauth_req_id
1c266114-a1be-4252-8ad1-
04986c5b9ac1
※クライアント認証に必要なパラメータは省略
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN",
"token_type": "Bearer",
"refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16",
"expires_in": 3600,
“id_token”: “eyJhbGciOiJSUzI1N(略)"
}
レスポンス
- 34. 33
CIBA(とその周辺)を実装してみて・・・
②3種類のモードがある
モード Poll Ping Push
概要
RPはトークンエンドポイントに対してポー
リング(定期的にリクエスト)を行う
AD上でユーザ同意が完了した後にリクエ
ストを行うと、トークンが返却される
AD上でユーザの同意が完了すると、OP
はRPに対して、完了通知を送る
通知を受け取ったRPはトークンリクエスト
を行う
AD上でユーザの同意が完了すると、OP
はRPに対してトークンを返却する
イメージ
実装ポ
イント
• 既存のトークンエンドポイントの拡
張なので比較的楽に実装でき
る!
• 複数RPがいる場合に性能考慮が
必要になる
• エラーレスポンス:slow_down
(ポーリング間隔5秒増やして)等
が定義されている
• 既存のトークンエンドポイントの拡
張なので比較的楽に実装できる
• OPは、RPがPollもできるように
実装しないといけない。→なら
Pollさえサポートしていればいい気
もする
• 完了通知のリトライ処理等、仕様
外での考慮が必要
• あまりオススメしません。
• 唯一既存のトークンリクエストと
向きが逆になるのでセキュリティ
考慮が必要
• サポートするなら、OPはIDトーク
ン内にもauth_req_idを埋めて、
RPに一連の要求であることをチェッ
クさせないといけない
RP OP
POST /token
まだ終わってないよ
終わったからtokenあげる
POST /token
RP OP終わったよ
POST /token
RP OP
token
tokenあげる
(OK)
(OK)
- 40. 39
色々あるOAuth2.0、OpenID Connectのバリエーション
◼ サードパーティが、ある情報を、所有者の承認
を得たうえで、アクセス可能(認可)にする
◼ ブラウザのような、認可のプロセスに必要な
UIを提供できないデバイスでも、OAuth2.0を
使いたい場合
◼ 誰が認証したかも確認したうえで認可(ID連
携)する必要がある場合
◼ 認証すべき人と別の人がID連携を必要とし、
認証すべき人が誰かを特定できる場合
◼ 認証すべき人と別の人がID連携を必要とし、
認証すべき人が誰かを特定できる場合で、且つ、
高いセキュリティレベルが求められる場合
◼ 金融サービス、または同等のセキュリティ
レベルが求められるサービスにて、ID連携を
実現する場合
認可
デバイス
(ブラウザ
無し)対応
認証
セキュリ
ティ
本人以外
から
リクエスト
開始
OAuth2.0
OAuth2.0
Device
Authorization
Grant
OpenID Connect
Core
(OIDC)
OIDC Client
Initiated
Backchannel
Authentication
(CIBA)
OIDC
FAPI CIBA
OIDC
Financial grade
API (FAPI)
And More...