「マイクロソフト系技術情報 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 の分離 †
- Device Flow
- 結果として CD と AD が分離
- OAuth Dance の RP -> IdP/STS(OP)にリダイレクトするタイミングで
リダイレクトではなく、QRコードやURL表示し、これを手元のスマートフォンに入力
- CIBA
- 最初から CD と AD が分離
- CD は、IdP/STS(OP)にCIBA独自の認証リクエストを行う。
- 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にそのまま表示する
ユーザ認証 †
- 認証デバイスでスマホのプッシュ通知を使う想定。
- 承認ボタン押下で、エンドポイントにレスポンスが帰る。
Tokenリクエスト・レスポンス †
- 認証リクエストの結果とTokenレスポンスを返す。
- 認証リクエストとの繋がりは非同期的なので、
Poll / Ping / Pushの3つの方式がある。
Poll †
Ping †
Push †
参考 †
OpenID †
TakahikoKawasaki? †
tkudo †
ritou †
r-weblife †
OIDC Client Initiated Backchannel Authentication Flow (CIBA)とは
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth