ユーザーがAuthorization Serverではなくクライアントへパスワードを入力し、クライアントがそのままToken Endpointへ転送します。信頼境界が広がるためOAuth 2.1では削除されています。
はじめに / 全体の流れ
このフローで、
何をするの？
このフローのゴール
アプリがパスワードを直接預かる旧方式の問題点を理解します。
代理人へ金庫の暗証番号そのものを教えるような方式です。現在は暗証番号を教えず、必要な権限だけを示す許可証を使います。
既存実装をAuthorization Code + PKCEへ移行し、クライアントがパスワードを扱わない構成を選べます。
登場人物
図では、縦の列ごとに担当者やシステムを分けています。
Operator
処理を開始する人や運用システムです。フローによっては途中から登場しません。
Client
ユーザーに代わって認可を依頼し、許可されたAPIを呼び出すアプリです。
Authorization
ログイン、同意、コードやトークンの発行を担当する信頼できるサーバーです。
Resource
アクセストークンを確認して、許可されたデータや機能を提供するAPIです。
図の読み方: 光る丸が今説明している通信です。自動再生を止めたいときは「Pause」を押し、気になる矢印を選んでください。
OOperatorResource Owner
CClientApplication
AAuthorizationToken Service
RResourceProtected API
01
Operator → Client
資格情報を入力
このステップで行うことユーザーがクライアント自身の画面へIDとパスワードを入力します。
REQUEST / RESPONSE EXAMPLEProtocol operation
REQUEST
username + password
Content-Type: application/json
Accept: application/jsonレスポンス
HTTP/1.1 200 OK
Content-Type: application/json
Accept: application/json
{ "status": "accepted" }※ トークン、challenge、Credential IDなどは説明用に短縮したサンプル値です。
Related flows