OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA）のご紹介 ~ その新しいUXと実装例のご紹介 - OpenID Summit 2020
•
2 likes•1,865 views
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA）のご紹介 ~ その新しいUXと実装例のご紹介 柴田 健久 - ＮＲＩセキュアテクノロジーズ株式会社 赤星 拓未 - ＮＲＩセキュアテクノロジーズ株式会社
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA）のご紹介 ~ その新しいUXと実装例のご紹介 - OpenID Summit 2020
Similar to OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA）のご紹介 ~ その新しいUXと実装例のご紹介 - OpenID Summit 2020 (20)
More from OpenID Foundation Japan
More from OpenID Foundation Japan (20)
Recently uploaded
Recently uploaded (9)
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」 開発リーダー。
- 3. 2 アジェンダ [デモ] OpenID Connect CIBAを実装してみました OpenID Connect CIBAとは？ CIBAのシーケンス CIBAを実装してみて・・・ OpenID Connect CIBAの可能性
- 4. さっそくデモをどうそ！
- 8. 7 FAPI CIBA Profileも存在します MODRNAワーキンググループで検討されたCIBA Coreに加えて、金 融グレードのセキュリティに対応するための追加要件としてのFAPI CIBA profileもあります。 主にCIBA Coreについて話します（FAPIも軽く）
- 9. 8 CIBAと認可コードフローの違い CIBAは、ユーザーやデバイスが分離している 認可コードフロー CIBA 考え方 「サービス利用」する際に、OP上で ユーザー自身が同一UAで 「認証/認可」を行う 「サービス利用」と「認証/認可」を行う デバイス・ユーザーを分離 CIBA Core Specに記載されているユースケース例 ①コールセンターのオペレータが、発信者を認証したい ②銀行の窓口係が、対面で顧客を認証したい ③ユーザーがPOS端末で行っている支払いをユーザーのスマートフォンで承認したい デバイス・ユーザーが分離しているとは？ 子の(親のカードを使った)支払いを親がスマートフォンで承認したい
- 11. 実装例とCIBAの仕様詳細
- 12. 11 デモのアーキテクチャ OPには、CIBA対応済み認可サーバー製品(Uni-ID Libra)を利用 ユーザへの通知基盤のみFirebaseを利用 Uni-ID Libra Firebase CM Sample RP Sample OP バックチャネル 認証EP トークンEP Amazon ECS プッシュ通知 Sample OP App FIDO Client FIDO RP 同意結果通知 同意画面表示 同意結果 通知EP ポーリング認証要求 プッシュ通知 同意結果
- 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など）
- 20. 19 ⑤バックチャネル認証レスポンス 認証リクエストを識別する一意の値が返却されます。 OP内でのチェック処理 クライアント認証 リクエストパラメーターの検証（署名されている場合は署名も検証） もらったヒントからユーザーを特定(どのヒントを処理できるかは事前に通知) Uni-IDでは、全てのヒントを実装済み 成功時のレスポンス エラー時のエラーコード ユーザーが特定できない login_hint_tokenが有効期限切れ など レスポンスボディ 必須 説明 値の例 備考 auth_req_id 必須 認証リクエストを識別する一意の 値 1c266114-a1be-4252- 8ad1-04986c5b9ac1 RPはこの値をトークン取得する際に指定する expires_in 必須 認証リクエストの有効期限 3600 トークンエンドポイントへのリクエスト時に有効期 限切れだった場合はエラーになる interval 任意 RPがトークンエンドポイントをポーリ ングする最小間隔(秒) 2 Pingモードでも返却してOK（OPからの通知を 待たずにトークンリクエストを行えてしまうから）
- 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（略）" } レスポンス
- 30. 29 CIBA(とその周辺)を実装してみて・・・ ①ヒントについて どのヒントをどう定義するのか パラメータチェック ヒントの正当性確認 ②RPが認証結果を知るための３種類のモードについて どれがいいのか？安全か？ ③Security & Privacy Considerationを守る実装 ④FAPI-プロファイルもチェックが必要 ⑤（仕様外）デバイス管理も考えないといけない 今回は、スマホアプリでログインした際にユーザーとFirebaseの トークンを紐付けてOP側で管理した
- 32. 31 CIBA(とその周辺)を実装してみて・・・ ①ヒントが複数ある どのヒントを使うか？どう定義するのか？ → OPRP間で調整 login_hint login_hint_token id_token_hint メアドとかTELを使うのは、 プライバシー影響があることを考慮する 定義なし。署名は必須 RP側で過去通常フローで受け取った IDトークンを保持しておく必要 id_token_hint ？ id_token_hint はRP側実装が大変かも？ 過去受け取ったIDトークンをユーザと紐付けて管理し、 認証要求時になんらかの方法でRP側でユーザーを特定し ないといけない でも、 いい感じなのは 特定ユースケースなら login_hint_token ADで払い出したlogin_hint_tokenをCDに読み込ませる (QRコード等)
- 33. 32 CIBA(とその周辺)を実装してみて・・・ ①ヒントが複数ある 認証要求時のパラメータチェック → OP側ちょっとだけ面倒 login_hint login_hint_token id_token_hint これらは独立したリクエストパラメーター どれか1つのみ送ってきて！ 2つ３つ同時に送ってこないで！ ヒントの正当性確認 → OP側考慮必要 を検証しよう 送られてきた expのチェックは意味がない！ 署名検証する際に既に鍵が古くなっている可能性がある その場合は署名検証せずに、id_token内のsubが確かにその client_idに紐づくもの(PPID)かを検証。ぐらいしかできない？ id_token_hint
- 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)
- 35. 34 ③Security Considerations RPがOPに送るヒントについて login_hint_tokenは、発行者による署名が必要。OPは署名をチェックすること。 クライアントから送られるid_token_hintは有効期限切れも考慮しなければいけない。 OIDC Coreで推奨されているチェックはそのまま使えない。OPができることは、 「自分が発行したIDトークンであること (issのチェック)」 「そのクライアントがaudienceクレームに含まれていること」 程度。 OPは、IDトークンの署名を検証する（IDトークンが変更されていないことを確認） ただし、署名鍵の rotation があると、署名検証できないので、その期間に要注意 署名検証せずppidのsubを受け入れることも検討可能。その場合は例えばバックチャンネ ルの認証エンドポイントにてクライアント認証した際に同一のsubが払い出されることで 検証する。(subはクライアントIDごとに異なる値にしておくことが前提) OPからRPへの通知について backchannel_client_notification_endpointが(ping、pushモードでのトークン通知先)が、クラ イアントの管理下にあることをOPが確認する必要がある。確認方法は仕様外。 クライアント側の検証(pushモード)：OPから突然プッシュされた各種トークンのハッシュと auth_req_idがIDトークンに含まれていることを確認（バインディングされていることを確認）
- 36. 35 ③Privacy Considerations Privacy Considerations login_hint(特定のヒントとなる何らかの識別子)のプライバシーを考慮する 電話番号やメールアドレスを使うとプライバシーに課題あり プライバシー要件がある場合は代替として ① id_token_hintを使う ② ADからCDに転送された使い捨てユーザIDを使う OPが払い出し、AD(認証用スマホ)でQRを表示。 CD(POSとか)がそれをスキャンし、それをlogin_hint_tokenとして送る ③ RPがユーザーをDiscovery serviceにsendし、暗号化された login_hint_tokenを受信し、それをリクエストパラメーターとして送る
- 37. 36 ④FAPI-CIBA Profile（一部のみ抜粋） 要求仕様 binding_messageは必須にすること pushモードをサポートしない（shall not） pollモードをサポートする（shall） pingをサポートしてもよい（may） 認証要求のパラメーターに署名すること 同意を要求する操作に適したユーザー認証を行うこと acrクレームをサポートすること 認証要求の有効期限（expクレーム）は60分以内にすること セキュリティ考慮 イタズラ認証要求対策（login_hintのみでADに認証要求できてしまう） id_tokenを使う。id_tokenを保持する際は正しいチャネルで取得したことを確認する もしくは、user_codeを使う 攻撃者が悪意のあるCIBAフローを本物と同時に開始したら、ユーザーは両方認可してしまうかもしれない ユーザーは、ADとCDに表示された binding_message を比較すること ユーザーの確認に依存したくない場合は、QRコードを介して認証デバイスに binding_message を伝達 させて検証する等の仕組みが必要
- 38. さいごに
- 39. 38 どんなところで使えるのか CIBA Core Specに記載されているユースケース例 ①コールセンターのオペレータが、発信者を認証したい ②銀行の窓口係が、対面で顧客を認証したい ③ユーザーがPOS端末で行っている支払いをユーザーのスマートフォンで承認したい 他に考えられるユースケース • 子の(親のカードを使った)支払いを親がスマートフォンで承認したい • カーシェアをしていて、クルマを使いたい人がオーナーに車を借りるとき • ロボットで自動取引をしているが、一定の条件を超えた取引は判断したい場合 認証すべき人と別の人がID連携を必要とし、 認証すべき人が誰かを特定できる場合
- 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...