![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -戻る --[[OAuth 2.0 拡張]] --[[OpenID Connect]] * 目次 [#x774c2a7] #contents *概要 [#ta7069e9] 「新たなユーザ認証体験」のベースとなりうるものらしい。 -デバイスを --サービス利用 --ユーザー認証 >に分離することによりユーザー認証体験の可能性が広がる。 -以下の両分野がCIBAの標準化を進めている。 --モバイル --金融API >※ CIBAは、シーバと読む。 [[FAPI>Financial API (FAPI)]]と、直接関係は無い。~ ※ OpenID Foundation の MODRNA（マッダーヌァ） WG (mobile系 の WG)で策定。 **用語 [#afb03bc6] -基本的な用語は、OAuth2/OIDCと変わらない。 -その他、以下の用語が追加されている。 --Consumption Device (CD)~ CIBA Flow ユーザ（なんでもOK）だが、~ 基本的にConfidential Clientを経由する。 --Authentication Device (AD) ~ 認証デバイスで、スマホのプッシュ通知を使う想定。 --BA EP（バックチャネル認証エンドポイント）~ AuthZ（IdP/STS）に追加される新たなエンドポイント。 **ユースケース [#n46fc07e] 以下のようなユースケースがある。 -銀行窓口での顧客認証 -コールセンターにおける発信者認証 -ユーザーのスマートフォンで POS 端末の支払い ***ポイント [#z9c24ef2] CIBAのユースケースのポイントは、 -認証リクエストする人と、 -スマホの承認ボタンを押下する人が、 違うコトであるもよう。 ***同一人物の場合 [#i7e625ea] -2FA的な意味合いも無いので微妙。 -パスワードレス的な意味はあるが、その場合、単純に、~ AuthZ（IdP/STS）をスマホのプッシュ通知に対応させればイイ。 **[[OAuth 2.0 Device Flow]]との違い。 [#se69e4c7] ***CD, AD の分離 [#c08888c1] -[[OAuth 2.0 Device Flow]] --通常のOAuthダンスのフローで RP -> IdP/STS（OP）と遷移してログインする。 --その後、Redirectではなく、URL / QRコードを表示し、これをスマートフォンに入力する。 -CIBA --CD は、IdP/STS（OP）にCIBA独自の認証リクエストを行う。 --IdP/STS（OP）が AD を用いて要求を認証するユーザと対話する。 ***事前のユーザー識別 [#refe6482] Clientの、事前のユーザー識別は必要か？ -[[OAuth 2.0 Device Flow]]~ 不要（OAuth2と同じく、ログインするので不要）。 -CIBA~ 必要になる。 --要求時、Client が IdP/STS（OP）に認証対象ユーザを通知する。 --IdP/STS（OP）は、AD を特定 して、プッシュ通知を行う。 *詳細（フロー） [#a3ba36e2] フローを見ると、RedirectによるOAuthダンスではなく、[[OAuth 2.0 Device Flow]]風で、~ デバイスへの通知にSMSではなく、スマホのプッシュ通知を使用している感じの仕様っポイ。 -従来の従来のOAuthダンスは「Redirect フロー」と言うらしい。 -CIBA は「Decoupled フロー」と言うらしい（decoupled and back-channel）。 --decoupled：~ Client（Webアプリとスマホ）と認証デバイス（≒スマホ）に分離。~ 其々のスマホを、Consumption Device (CD) 、Authentication Device (AD)と言うらしい。 --back-channel：~ AuthZはback-channelで認証要求を受付け、認証結果を返す(Poll / Ping / Push)。 **認証リクエスト・レスポンス [#k24365ee] -認可リクエストではないことに注意。 -認証リクエストを受け付けてレスポンスする（以後、非同期的に処理）。 ***ユーザ特定 [#y479f65b] クライアントがAuthZのバックチャネル認証エンドポイントにリクエストを投げる際、 -以下のパラメタのどれか一つをヒントとしてサーバに渡す。 --login_hint_token --id_token_hint --login_hint -サーバはそのヒントを元に認証対象ユーザを特定する。 ***認証要求の正当性 [#z8711778] 認証デバイスに飛んできた認証要求が正当なものかどうかを確認するためのパラメタ -Binding Message --かなり短い単純な文字列であることが想定されている。 --Biding MessageをADにそのまま表示する -user_code **ユーザ認証 [#r0e5aee2] ***通知->認証 [#ree84563] -特定した認証対象ユーザのスマホにプッシュ通知を送信する。 -認証ボタン押下で、エンドポイントにレスポンスが帰る。 ***非同期処理 [#g940bf67] プッシュ通知を送信した後、認証ボタンが押下される間、~ IdP/STS（OP）は、その認証に一意にひもづく識別子をClientに返す。 **Tokenリクエスト・レスポンス [#ae7a371f] -上記の識別子を使用してTokenリクエストする。 -これにより、認証リクエストの結果とTokenレスポンスを返す。 -認証リクエストとの繋がりは非同期的なので、以下の、Poll / Ping / Pushの3つの方式がある。 ***Poll [#wd99403b] Client は IdP/STS（OP）の Token Endpoint を~ 認証の識別子と共にポーリングして応答を受け取る。 ***Ping [#e0ee3a25] -事前に Client が登録しておいた Callback URI に対して~ IdP/STS（OP）が認証の識別子と共に通知用のリクエストを送る。 -その後、Client は Token Endpoint からトークンを取得する。 ***Push [#b91022f2] 事前に Client が登録しておいた Callback URI に対して~ IdP/STS（OP）がトークンを含むリクエストを送る。 *参考 [#hdf3c138] -openid / fapi / 課題 / #127 - CIBA: security issues — Bitbucket~ https://bitbucket.org/openid/fapi/issues/127/ciba-security-issues -Authlete を使って CIBA 対応の認可サーバーを作る~ https://qiita.com/hidebike712/items/8fc2938055d0b49cfc0a **OpenID [#maf4557e] -OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-01~ https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html -Public Review Period for OpenID Connect Client Initiated Backchannel Authentication (CIBA) Core Started~ https://openid.net/2018/12/14/public-review-period-for-openid-connect-client-initiated-backchannel-authentication-ciba-core-started/ **TakahikoKawasaki [#w6fc5ef3] -【2019年版】世界最先端の認証認可技術、実装者による『CIBA』解説~ https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3 **tkudo [#t0cf0a95] -CIBA (Client Initiated Backchannel Authentication) の可能性~ https://www.slideshare.net/tkudo/openid-connect-ciba-overview -FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication)~ https://www.slideshare.net/tkudo/fapi-ciba-2019-03-28 **ritou [#f98f2c49] ***r-weblife [#g9a31a97] -OIDC Client Initiated Backchannel Authentication Flow (CIBA)とは --概要編~ https://ritou.hatenablog.com/entry/2018/12/29/224452 --詳細もとい感想編~ https://ritou.hatenablog.com/entry/2019/03/04/005238 -twitter.com --https://twitter.com/ritou/status/1120863238038511616 ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
