「マイクロソフト系技術情報 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
- Device は、IdP/STS（OP）にDevice Flow独自バックチャネルに認証リクエストを行う。
- Device は、IdP/STS（OP）から受け取ったURIとCodeを画面に表示する（QRやNFCなども利用可能）。
- ユーザは、URIでIdP/STS（OP）に接続し、対話する（認可 or 拒否）。
- 上記の後、Device は、TokenリクエストをBackchannelからポーリングなどで行う。
- CIBA
- CD は、IdP/STS（OP）にCIBA独自バックチャネルに認証リクエストを行う。
- IdP/STS（OP）が AD を用いて要求を認証するユーザに通知する。
- ユーザは、通知をトリガにして AD に遷移して対話する（認可 or 拒否）。
- 上記の後、CD は、TokenリクエストをBackchannelからポーリングなどで行う。
事前のユーザー識別 †
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にそのまま表示する。
- user_code
- 使用する・しないを選択可能。
- Authentication Device (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）がトークンを含むリクエストを送る。
- PPIDの利用（subject_type が pairwiseのとき）
- PollingモードとPingモード
- 登録フェーズでjwks_uriを提供する必要がある。
- sector_identifier_uriを提示する場合、ここに、jwks_uriを含める。
- jwks_uriの妥当性はクライアント認証を用いることで検証可能。
- Pushモード
- backchannel_client_notification_endpointを使用する。
- sector_identifier_uriを提示する場合、
ここに、backchannel_client_notification_endpointを含める。
- jwks_uri異なり、妥当性の検証は不要。
その他 †
メタデータ †
- grant_types
grant_types_supported に urn:openid:params:grant-type:ciba を追加。
- 認可エンドポイント
backchannel_authentication_endpoint を追加。
- 非同方式
backchannel_token_delivery_modes_supported : ["poll", "ping", "push"]
- 認可リクエストの署名アルゴリズム
backchannel_authentication_request_signing_alg_values_supported
- user_codeのサポートの有無（デフォルト値はfalse）
backchannel_user_code_parameter_supported
- 非同方式
backchannel_token_delivery_mode : "poll" or "ping" or "push"
- PingまたはPushの際のCallbackエンドポイント
backchannel_client_notification_endpoint
- 認可リクエストの署名アルゴリズム（既定値は署名無し）
backchannel_authentication_request_signing_alg
- user_codeのサポートの有無（デフォルト値はfalse）
backchannel_user_code_parameter
- 登録の例
POST /connect/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
{
"application_type": "web",
"client_name": "My Example",
"logo_uri": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"token_endpoint_auth_method": "private_key_jwt",
"grant_types": ["urn:openid:params:grant-type:ciba"],
"backchannel_token_delivery_mode": "poll",
"jwks_uri": "https://client.example.org/my_public_keys.jwks",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC-HS256",
"contacts": ["ve7jtb@example.org", "mary@example.org"]
}
セキュリティ考慮事項 †
参考 †
OpenID †
TakahikoKawasaki? †
tkudo †
ritou †
- OIDC Client Initiated Backchannel Authentication Flow (CIBA)とは
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
