![[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は、シーバと読み「新たなユーザ認証体験」のベースとなりうるものらしい。 -デバイスを --サービス利用 --ユーザー認証 >に分離することによりユーザー認証体験の可能性が広がる。 -以下の両分野がCIBAの標準化を進めている。 --モバイル --金融API >※ OpenID Foundation の MODRNA（マッダーヌァ） WG (mobile系 の WG)で策定。~ MODRNA : Mobile Operator Discovery, Registration & autheNticAtion. **イメージ [#z474bd0a] #ref(ciba.png,left,nowrap,CIBA) **用語 [#afb03bc6] -基本的な用語は、OAuth2/OIDCと変わらない。 -その他、以下の用語が追加されている。 ***Consumption Device (CD) [#gfdf9430] CIBA Flow ユーザ（なんでもOK）だが、~ 基本的にConfidential Client(RP)を経由する。 ***Authentication Device (AD) [#n4cd6119] -認証デバイス~ EndUser（≒ Resource Owner）の~ 所有物として認証されているデバイス。 -Publicであるが、Public "Client"ではない。 --要するに、従来の[[OAuth2の登場人物>OAuth#zb38b595]]の範囲外 --従って、CIBAの仕様上でも、仕様の詳細は語られない。 -認証デバイスへの通知には、スマホの[[プッシュ通知>#v6eb33df]]を使う想定。 ***BA EP（バックチャネル認証エンドポイント） [#u44eb79c] フロントエンドからリーチしない~ Confidential Client(RP)経由の~ バックチャネルと言う事だろうか。 -AuthZ（IdP/STS）に追加される新たな認証エンドポイント。 -AuthZは[[CD>#gfdf9430]]からRP経由で認証リクエストを受付け、 -非同期で、[[CD>#gfdf9430]]にRP経由で認証レスポンスを返す(Polling / Ping / Push)。 ***その他、用語の差異 [#c4cd478c] -認可リクエストではなく認証リクエスト -しかし、AuthZ は AuthZ。AuthNではない。 -Resource Owner ではなく EndUser（ユーザ） **ユースケース [#n46fc07e] 以下のようなユースケースがある。 -銀行窓口での顧客認証 -コールセンタにおける発信者認証 -ユーザのスマホで POS 端末の支払い ***ポイント [#z9c24ef2] CIBAのユースケースのポイントは、 -認証リクエストする人と、 -スマホの認可 or 拒否ボタンを押下する人が、 違うコトであるもよう。 ***同一人物の場合 [#i7e625ea] -2FA的な意味合いも無いので微妙。~ （CIBAの[[AD>#n4cd6119]]を2FAに転用することは可能だが） -パスワードレス的な意味も無い。 --仕様に詳しく書かれていないが、[[AD>#n4cd6119]]であっても認証処理は行うため。 --AuthZ と [[AD>#n4cd6119]] が [[FIDO]] や [[WebAuthn>Web Authentication API]]認証に対応していれば別だが。 **[[OAuth 2.0 Device Flow]]との違い。 [#se69e4c7] ***[[CD>#gfdf9430]], [[AD>#n4cd6119]] の分離 [#c08888c1] 認可リクエストを行う人と、認可 or 拒否ボタンを押下する人が違う。 -[[OAuth 2.0 Device Flow]] --Device は、 ---IdP/STS（OP）にDevice Flow独自エンドポイントに認証リクエストを行う。 ---認証レスポンスから受け取ったURIとCodeを画面に表示する（[[QRコード>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?QR%E3%82%B3%E3%83%BC%E3%83%89]]やNFCなども利用可能）。 --ユーザは、URIでIdP/STS（OP）に接続し、対話する（認可 or 拒否）。~ （仕様に詳しく書かれていないが、AuthZ Serverに追加した画面に認証後にアクセス） --上記の後、Device は、TokenリクエストをPollingする。 -CIBA --[[CD>#gfdf9430]] は、IdP/STS（OP）にCIBA独自バックチャネルに認証リクエストを行う。 --IdP/STS（OP）が [[AD>#n4cd6119]] を用いて要求を認証するユーザに[[プッシュ通知>#v6eb33df]]する。 --ユーザは、[[プッシュ通知>#v6eb33df]]をトリガにして [[AD>#n4cd6119]] に遷移して対話する（認可 or 拒否）。~ （仕様に詳しく書かれていないが、[[PKCE>OAuth PKCE]]などで認証処理を行う必要がある） --上記の後、[[CD>#gfdf9430]] は、Tokenリクエストを[[Pollingなど>#qe881045]]で行う。 ***事前のユーザー識別 [#refe6482] Clientの、事前のユーザー識別は必要になる。 -[[OAuth 2.0 Device Flow]] --不要（ユーザは１名） --認可 or 拒否ボタンを押下する画面を~ 参照するためにAuthZにログインしたユーザが唯一のユーザ -CIBA~ 必要（ユーザは２名） --[[CD>#gfdf9430]] ---要求時、Client が IdP/STS（OP）に認証対象ユーザを通知する。 ---IdP/STS（OP）は、認証対象ユーザの[[AD>#n4cd6119]]を特定 して、[[プッシュ通知>#v6eb33df]]を行う。 --[[AD>#n4cd6119]]~ 仕様に詳しく書かれていないが、[[AD>#n4cd6119]]でも認証が必要になる。 *詳細（フロー） [#a3ba36e2] フローを見ると、RedirectによるOAuthダンスではなく、[[OAuth 2.0 Device Flow]]風で、~ デバイスへの通知にSMSではなく、スマホの[[プッシュ通知>#v6eb33df]]を使用している感じの仕様っポイ。 -従来の従来のOAuthダンスは「Redirect フロー」と言うらしい。 -CIBA は「Decoupled フロー」と言うらしい（decoupled and back-channel）。 --decoupled： ---Client（Webアプリ）と認証デバイス（≒スマホ）に分離。 ---其々のスマホを、[[Consumption Device (CD) 、Authentication Device (AD)>#afb03bc6]]と言う。 --back-channel：~ [[BA EP（バックチャネル認証エンドポイント）>#afb03bc6]] **認可エンドポイント [#k24365ee] 認証リクエストを受け付けて直ちにレスポンスする（以後、非同期的に処理）。 ***認可リクエスト [#y479f65b] -ユーザ特定が必要になるので、 --クライアントがAuthZの認証リクエストを投げる際、~ 以下のパラメタのどれか一つをヒントとしてサーバに渡す。 ---login_hint_token ---id_token_hint ---login_hint --サーバはそのヒントを元に認証対象ユーザを特定する。 -パラメタ --scope ---OAuth2.0のscopeと同じ。 ---CIBAではopenidスコープ値が含まれている必要がある。 --client_notification_token ---Ping / Pushモードの際のCallback URIに渡すBearer Token ---1024文字以下（128bit以上で、160bit前後）の乱数を含む自己完結型 --acr_values (OPTIONAL)~ [[認証コンテキスト クラス>OpenID Connect - Authentication Context Class Reference]]値 --各種ヒント (OPTIONAL) ---login_hint~ エンドユーザーを識別するe-mail、TEL、sub、userName、userIdなど ---login_hint_token~ エンドユーザーを識別するためのトークン~ （署名が必要≒JWS） ---id_token_hint~ エンドユーザーを識別するためのIDトークン~ （JWS or JWEでissとaudを検証、期限切れも処理） --認証デバイスに飛んできた認証要求が~ 正当なものかどうかを確認するためのパラメタ。 ---binding_message (OPTIONAL)~ ・かなり短い単純な文字列であることが想定されている。~ ・Biding Messageを[[CD>#gfdf9430]]と[[AD>#n4cd6119]]の画面に「表示」する。~ ・比較的短く、プレーンテキスト文字の限られたセットを使用する ---user_code (OPTIONAL)~ ・未認証状態で送信可能な[[プッシュ通知>#v6eb33df]]技術のために用意されている。~ ・認証状態でのみ利用可能な[[プッシュ通知>#v6eb33df]]の場合、使用しないを選択可能。~ ・backchannel_user_code_parameterがtureの場合、configとして必須となる。~ ・[[AD>#n4cd6119]]の[[プッシュ通知>#v6eb33df]]に表示し、応答で入力させる。 --requested_expiry (OPTIONAL)~ auth_req_idのexpires_in値を要求できるようにする正の整数。 -クライアント認証方法 --client_idや、[[JWT bearer token authorizationグラント種別]]のclient_assertionおよびclient_assertion_type。 --推奨は、公開鍵暗号で、署名有り認可リクエスト（[[Requestオブジェクト>OpenID Connect - Requestオブジェクト]]）を使用する場合は、そのものの検証でOK。 -リクエスト例 --署名無し POST /bc-authorize HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded scope=openid%20email%20example-scope& client_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255& binding_message=W4SCT& login_hint_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --署名有り~ [[Requestオブジェクト>OpenID Connect - Requestオブジェクト]]を使用 ---Request自体 POST /bc-authorize HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded request=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ---[[Requestオブジェクト>OpenID Connect - Requestオブジェクト]]~ 別途、iss, aud, exp, iat, nbf, jtiの追加が必要（JWSのみでJWEはサポートされない）。 { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "exp": 1537820086, "iat": 1537819486, "nbf": 1537818886, "jti": "4LTCqACC2ESC5BWCnN3j58EnA", "scope": "openid email example-scope", "client_notification_token": "8d67dc78-7faa-4d41-aabd-67707b374255", "binding_message": "W4SCT", "login_hint_token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } ***認可レスポンス [#z8711778] -パラメタ --auth_req_id ---必須。 ---[[プッシュ通知>#v6eb33df]] → 認証ボタン押下を識別するトランザクション識別子。 ---1024文字以下（128bit以上で、160bit前後）の乱数を含む自己完結型 --expires_in ---必須 ---auth_req_id、user_codeの有効期間（秒）。 --interval ---オプション ---Polling / Pingの間隔 --認証デバイスに飛んできた認証要求が~ 正当なものかどうかを確認するためのパラメタを返す。 ---binding_message ---user_code ---binding_message (OPTIONAL)~ ・かなり短い単純な文字列であることが想定されている。~ ・Biding Messageを[[CD>#gfdf9430]]と[[AD>#n4cd6119]]の画面に「表示」する。~ ・比較的短く、プレーンテキスト文字の限られたセットを使用する ---user_code (OPTIONAL)~ ・未認証状態で送信可能な[[プッシュ通知>#v6eb33df]]技術のために用意されている。~ ・認証状態でのみ利用可能な[[プッシュ通知>#v6eb33df]]の場合、使用しないを選択可能。~ ・backchannel_user_code_parameterがtureの場合、configとして必須となる。~ ・[[AD>#n4cd6119]]の[[プッシュ通知>#v6eb33df]]に表示し、応答で入力させる。 -レスポンス例 --成功 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1", "expires_in": 3600, "interval": 2 } --失敗 ---HTTP/1.1 400 Bad Request~ invalid_request, invalid_scope, expired_login_hint_token, unknown_user_id, ~ unauthorized_client, missing_user_code, invalid_user_code, invalid_binding_message Content-Type: application/json { "error": "unauthorized_client", "error_description": "The client 'client.example.org' is not allowed to use CIBA." } ---HTTP 401 Unauthorized Content-Type: application/json { "error": "invalid_client", "error_description": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } ---HTTP 403 Forbidden Content-Type: application/json { "error": "access_denied", "error_description": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } ***エラーの返却 [#ra040afb] -POSTのJSON返却なので、[[Tokenエンドポイントのレスポンス（失敗）>#z70c2acf]]と同じ。 -以下のレスポンスは、user_codeを要求するCIBAで追加されたエラー・レスポンスらしい。 HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"missing_user_code" } **通知->認証 [#r0e5aee2] ***通知 [#ree84563] 特定した認証対象ユーザのスマホに[[プッシュ通知>#v6eb33df]]を送信する。 -binding_messageを表示する。 -[[CD>#gfdf9430]]から指定された場合は、user_codeを入力させる。 ***認証 [#p4811805] PKCE認証などして、認可 or 拒否ボタン押下で、結果をIdP/STS（OP）に伝える（？） **Tokenエンドポイント [#ae7a371f] -上記の識別子を使用してTokenリクエストする。 -これにより、認証リクエストの結果とTokenレスポンスを返す。 -認証リクエストとの繋がりは非同期的なので、以下の、Polling / Ping / Pushの3つの方式がある。 ***Tokenリクエスト [#td76b143] -概要 --認可リクエストの成功を確認した後、TokenリクエストのPolling / Pingを始める。 --Pushの場合は、Pushをトリガにして、動き出す（しかし、結局、Client 側は待機している）。 -パラメタ --grant_type=urn:openid:params:grant-type:ciba --auth_req_id -リクエスト例 POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW grant_type=urn%3Aopenid%3Aparams%3Agrant-type%3Aciba &auth_req_id=1c266114-a1be-4252-8ad1-04986c5b9ac1 ***Tokenレスポンス [#z70c2acf] -成功~ [[OIDC>OpenID Connect#q4d3f512]]の認可レスポンス（成功）と同じ。 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN", "token_type": "Bearer", "refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16", "expires_in": 3600, "id_token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } -失敗~ [[OAuth 2.0>OAuth#n037bd41]]の認可レスポンス（失敗）に以下のパラメタを追加 --パラメタ（≒エラーコード） ---authorization_pending~ 認可リクエストは保留中 ---slow_down~ "authorization_pending"の変形で~ Polling間隔を5秒遅らせろの意味。 ---access_denied~ Resource Owner（EndUser）は、承認要求を拒否。 ---expired_token~ auth_req_id、user_codeの有効期限が切れた。 ---unauthorized_client~ PushモードのためCIBAでのTokenリクエストは不可。 --レスポンス例~ ・・・ ***ポイント [#qe881045] -非同期方式 --Poll~ Client は IdP/STS（OP）の Token Endpoint を~ 認証の識別子と共にPollingして応答を受け取る。 +--------+ +--------+ | | | | | |<---(1) CIBA Request-------------------------->| | | | | | | | +--------+ | | | | | | | | | Client | | AD |<--(2) User interactions---------->| OP | | | | | | | | | +--------+ | | | | | | | |----(3a) CIBA Polling Request----------------->| | | |<---(3b) CIBA Polling Response-----------------| | | | ... | | | |----(3a) CIBA Polling Request----------------->| | | |<---(3b) CIBA Polling Response-----------------| | | | | | +--------+ +--------+ --Ping~ 事前に Client が登録しておいた Callback URI に対して~ IdP/STS（OP）が認証の識別子と共に通知用のリクエストを送る。 +--------+ +--------+ | | | | | |<---(1) CIBA Request-------------------------->| | | | | | | | +--------+ | | | | | | | | | Client | | AD |<--(2) User interactions---------->| OP | | | | | | | | | +--------+ | | | | | | | |<---(3) CIBA Ping Callback---------------------| | | | | | | |----(4a) CIBA Token Request------------------->| | | |<---(4b) CIBA Token Response-------------------| | +--------+ +--------+ ---以下の成功のレスポンスを受け取り、Bearerが、~ 無効な場合、HTTP 204 No Content or HTTP 200 OK をレスポンス。~ 無効な場合、HTTP 401 Unauthorized をレスポンス。 POST /cb HTTP/1.1 Host: client.example.com Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255 Content-Type: application/json { "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1" } ---以下の失敗のレスポンスを受け取り、Bearerが、~ 無効な場合、HTTP 204 No Content or HTTP 200 OK をレスポンス。~ 無効な場合、HTTP 401 Unauthorized をレスポンス。 POST /cb HTTP/1.1 Host: client.example.com Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255 Content-Type: application/json { "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1", "error": "access_denied" or "expired_token" or "transaction_failed", "error_description": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } ---成功のレスポンスの後、Client は Tokenリクエストを行いTokenレスポンスを取得する。 ---良く解らないが、Pingで構成されたClientはPollingも可能らしい。 --Push ---事前に Client が登録しておいた Callback URI に対して~ IdP/STS（OP）がトークンを含むリクエストを送る。 +--------+ +--------+ | | | | | |<---(1) CIBA Request-------------------------->| | | | | | | | +--------+ | | | | | | | | | Client | | AD |<--(2) User interactions---------->| OP | | | | | | | | | +--------+ | | | | | | | |<---(3) CIBA Push Callback---------------------| | | | | | +--------+ +--------+ ---Tokenレスポンス・ライクなレスポンスが返り、Bearerが、~ 無効な場合、HTTP 204 No Content or HTTP 200 OK をレスポンス。~ 無効な場合、HTTP 401 Unauthorized をレスポンス。 POST /cb HTTP/1.1 Host: client.example.com Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255 Content-Type: application/json { "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1", "access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN", "token_type": "Bearer", "refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16", "expires_in": 3600, "id_token": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" } ---id_tokenを検証する（改ざんされていないか確認）。~ urn:openid:params:jwt:claim:auth_req_idの一致と、~ at_hashを使用したaccess_token検証~ rt_hashを使用したrefresh_token検証 { "iss": "https://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "email": "janedoe@example.com", "exp": 1537819803, "iat": 1537819503, "at_hash": "Wt0kVFXMacqvnHeyU0001w", "urn:openid:params:jwt:claim:rt_hash": "sHahCuSpXCRg5mkDDvvr4w", "urn:openid:params:jwt:claim:auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1" } -[[PPID>OpenID Connect#m3999d6f]]の利用（subject_type が pairwiseのとき） --Polling / Pingモード ---PPID計算のセクター識別子としてjwks_uriを使用する。 ---故に、登録フェーズでjwks_uriを提供する必要がある。 ---sector_identifier_uriを提示する場合、ココに、jwks_uriを含める。 ---jwks_uriの妥当性はクライアント認証を用いることで検証可能。 --Pushモード ---PPID計算のセクター識別子としてbackchannel_client_notification_endpointを使用する。 ---sector_identifier_uriを提示する場合、ココに、backchannel_client_notification_endpointを含める。 ---jwks_uri異なり、backchannel_client_notification_endpointの妥当性検証は不要。 --[[PPID計算のセクター識別子の登録の例>#ca31c8b1]]。 --[[FAPI Profileでの気付き。>#of2b90f9]] **その他 [#hbe781e6] ***メタデータ [#ca31c8b1] -IdP --必須 ---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 -Client --必須 ---非同方式~ 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"] } ***セキュリティ考慮事項 [#ga4f18e9] -PPIDを含むIDトークン~ 使用可能である模様（確かにclient_idでPPID計算のセクター識別子を特定可）。 -使い捨てユーザーID~ [[AD>#n4cd6119]]で認証後にIDを生成し、[[QRコード>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?QR%E3%82%B3%E3%83%BC%E3%83%89]]で[[CD>#gfdf9430]]にlogin_hint_tokenを転送 -ディスカバリー・サービス~ RPがユーザーをディスカバリサービスからlogin_hint_tokenを受信 *[[FAPI>Financial API (FAPI)]] [#fc870e7d] -CIBAは、FAPIと直接関係は無いが、 -FAPI-CIBA プロファイルという新仕様がUK OBIEから寄付（2019 年 8 月に承認）。 -プロファイルは、読み取り専用APIと読み取り/書き込みAPIの両方に適用される。 -以下が前提知識として必要になる。 --[[FAPI Part 1 (Read Only API Security Profile)]] --[[FAPI Part 2 (Read and Write API Security Profile)]] **要約 [#l8e736a2] ***AuthN Server [#of2b90f9] -FAPI-CIBA プロファイルを使えるのはConfidential Clientのみ。 -認可リクエスト --JARを使用する。 ---nbf クレームと exp クレームを含む。 ---JWT の生存期間は 60 分以内。 ---PPIDについては（、redirect_uriが無いので）、request_uri(URN)を使う？~ ...その場合、URNのヘッダ部分をClient毎に固定する必要があるかもしれない。~ （そもそもCIBAは外部ログインには使用しないので、匿名になりさえすれば良さそう）~ （また、そもそもCIBAするClientは、名寄せなどを行わなそうなのでPPIDも不要かも。） --request_context パラメーターが含まれることを要求してもよい。 ---詐欺や脅威の決定を知らせるJSONオブジェクト（内容は仕様で定義されていない）。 ---例：[[CD>#gfdf9430]]に位置情報を提供するために、信頼関係者が必要になる場合がある。 --login_hint や login_hint_token を流用してはならない。~ （流用とは、例えば、この項目を下記の意図（intent）に使用するなど。） --複雑な認可パラメタを伝える場合、"lodging intent"パターンを考慮する。~ 例えば、アクセスの範囲（scope）ではなくて、意図（intent）を指定する。~ （intentは、[[PARやRAR>JWTとOAuth2.0#o9b238a2]]で指定するとのことだが、ココではPARになる）。 -非同期方式 --Pollingモードをサポートしなければならない --Pushモードをサポートしてはならない --Pingモードをサポートしてもよい -以下の何れかが必須 --認可コンテキストが一意（抽象的） --binding_messageが必須（具体的） ***Client [#r6cb2be5] -[[CD>#gfdf9430]] --[[CD>#gfdf9430]]は、下記ヘッダを送信してはならない ---x-fapi-auth-date ---x-fapi-consumer-ip-address --代わりに、以下の情報を送るべきである ---位置情報 ---デバイスタイプ **セキュリティ考慮事項 [#cff6ebb6] -login_hint や login_hint_token --login_hintに広く知られている識別子（電話番号など）使用される場合のリスク --login_hint_tokenはチャネルに適切であることを確認する必要がある。 -binding_messageに加え、~ （必要に応じて）user_code パラメタも使用した方がイイ。 -JWT署名 --ES256 と PS256のみ許可 --RSA1_5（≒ RSXXX）は禁止 -TLS~ 暗号スイートの許可リストに含めるべき。 --TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 --TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 *参考 [#hdf3c138] **内部 [#tbb9bcdf] ***[[Financial API (FAPI)]] [#me75d2c7] ***[[プッシュ通知>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%83%97%E3%83%83%E3%82%B7%E3%83%A5%E9%80%9A%E7%9F%A5]] [#v6eb33df] **外部 [#d899d631] -openid / fapi / 課題 / #127 - CIBA: security issues — Bitbucket~ https://bitbucket.org/openid/fapi/issues/127/ciba-security-issues -【技術解説】OpenID Connect CIBA 実装の具体例と考慮すべきポイント~ https://www.secure-sketch.com/blog/openid-connect-ciba-implementation ***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 -Financial-grade API: Client Initiated Backchannel Authentication Profile~ https://openid.net/specs/openid-financial-api-ciba-ID1.html ***TakahikoKawasaki [#w6fc5ef3] -Qiita --【2019年版】世界最先端の認証認可技術、実装者による『CIBA』解説~ https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3 --FAPI-CIBA プロファイル~ https://qiita.com/TakahikoKawasaki/items/f478e2fd07b7236d6fbe --Authlete を使って CIBA 対応の認可サーバーを作る~ https://qiita.com/hidebike712/items/8fc2938055d0b49cfc0a ***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] -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 --CIBAの認証フローを体験するためのWebアプリ(途中経過)~ https://ritou.hatenablog.com/entry/2019/06/03/070000 **OSSコンソーシアム [#j68b8691] ***開発基盤部会 Blog [#m4873357] -FAPI-CIBAプロファイルを実装してみようかな~ （次いでにOAuth2 Device Flowも）。~ https://www.osscons.jp/jovbqpaa0-537/ -FAPI-CIBA プロファイルの実装を開始した。~ https://www.osscons.jp/jov3wu676-537/ -[[CIBA開発に見た。スタックは出来るがコラボが難しい件のディティール>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%EF%BC%86%E3%82%B3%E3%83%A9%E3%83%9C%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3#d41ee884]] ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
