「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
「新たなユーザ認証体験」のベースとなりうるものらしい。
に分離することによりユーザー認証体験の可能性が広がる。
※ CIBAは、シーバと読む。 FAPIと、直接関係は無い。
※ OpenID Foundation の MODRNA（マッダーヌァ） WG (mobile系 の WG)で策定。
用語 †
- 基本的な用語は、OAuth2/OIDCと変わらない。
- Consumption Device (CD)
CIBA Flow ユーザ（なんでもOK）だが、
基本的にConfidential Clientを経由する。
- Authentication Device (AD)
認証デバイスで、スマホのプッシュ通知を使う想定。
- BA EP（バックチャネル認証エンドポイント）
AuthZ（IdP/STS）に追加される新たなエンドポイント。
ユースケース †
以下のようなユースケースがある。
- 銀行窓口での顧客認証
- コールセンターにおける発信者認証
- ユーザーのスマートフォンで POS 端末の支払い
ポイント †
CIBAのユースケースのポイントは、
- 認証リクエストする人と、
- スマホの承認ボタンを押下する人が、
違うコトであるもよう。
同一人物の場合 †
- パスワードレス的な意味はあるが、その場合、単純に、
AuthZ（IdP/STS）をスマホのプッシュ通知に対応させればイイ。
CD, AD の分離 †
- OAuth 2.0 Device Flow
- 通常のOAuthダンスのフローで RP -> IdP/STS（OP）と遷移してログインする。
- その後、Redirectではなく、URL / QRコードを表示し、これをスマートフォンに入力する。
- CIBA
- CD は、IdP/STS（OP）にCIBA独自の認証リクエストを行う。
- IdP/STS（OP）が AD を用いて要求を認証するユーザと対話する。
事前のユーザー識別 †
Clientの、事前のユーザー識別は必要か？
- CIBA
必要になる。
- 要求時、Client が IdP/STS（OP）に認証対象ユーザを通知する。
- IdP/STS（OP）は、AD を特定 して、プッシュ通知を行う。
詳細（フロー） †
フローを見ると、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)。
認証リクエスト・レスポンス †
- 認可リクエストではないことに注意。
- 認証リクエストを受け付けてレスポンスする（以後、非同期的に処理）。
ユーザ特定 †
クライアントがAuthZのバックチャネル認証エンドポイントにリクエストを投げる際、
- 以下のパラメタのどれか一つをヒントとしてサーバに渡す。
- login_hint_token
- id_token_hint
- login_hint
- サーバはそのヒントを元に認証対象ユーザを特定する。
認証要求の正当性 †
認証デバイスに飛んできた認証要求が正当なものかどうかを確認するためのパラメタ
- Binding Message
- かなり短い単純な文字列であることが想定されている。
- Biding MessageをADにそのまま表示する
ユーザ認証 †
通知->認証 †
- 特定した認証対象ユーザのスマホにプッシュ通知を送信する。
- 認証ボタン押下で、エンドポイントにレスポンスが帰る。
非同期処理 †
プッシュ通知を送信した後、認証ボタンが押下される間、
IdP/STS（OP）は、その認証に一意にひもづく識別子をClientに返す。
Tokenリクエスト・レスポンス †
- 上記の識別子を使用してTokenリクエストする。
- これにより、認証リクエストの結果とTokenレスポンスを返す。
- 認証リクエストとの繋がりは非同期的なので、以下の、Poll / Ping / Pushの3つの方式がある。
Poll †
Client は IdP/STS（OP）の Token Endpoint を
認証の識別子と共にポーリングして応答を受け取る。
Ping †
- 事前に Client が登録しておいた Callback URI に対して
IdP/STS（OP）が認証の識別子と共に通知用のリクエストを送る。
- その後、Client は Token Endpoint からトークンを取得する。
Push †
事前に Client が登録しておいた Callback URI に対して
IdP/STS（OP）がトークンを含むリクエストを送る。
参考 †
OpenID †
TakahikoKawasaki? †
tkudo †
ritou †
r-weblife †
OIDC Client Initiated Backchannel Authentication Flow (CIBA)とは
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
