3.1. Initial Authorization Request

ファーストパーティクライアントはユーザーにサインインボタンを表示したり、メールアドレスやユーザー名などの情報をユーザーから収集することでフローを開始する
クライアントは Authorization Challenge Endpoint への POST request （任意でメールアドレスやユーザー名などを指定）によって認可リクエストを初期化する
認可サーバーは Authorization Challenge Endpoint に渡された情報が認可に十分かどうかを判断し、認可コードまたはエラーをレスポンスする。例えば、さらなる情報が必要な場合はエラーをレスポンスする。このエラーはクライアントが追加で収集すべき情報をガイドするかもしれない。情報の収集、Authorization Challenge Endpoint への送信、エラーもしくは認可コードの取得のパターンは何回か繰り返されるかもしれない。
クライアントは署名済みのパスキーのチャレンジや、メール経由での OTP のような情報を収集し、 Authorization Challenge Endpoint に POST リクエストを行う
Authorization Challenge Endpoint は認可コードを返す
クライアントはトークン取得のため、取得した認可コードを Token Endpoint に送信する
認可サーバーはトークンエンドポイントからアクセストークンを返す

inabajunmr

Resource Owner Password Credentials grant を柔軟にしたやつって感じ？

inabajunmr

4.1. Authorization Challenge Endpoint

ファーストパーティが認可コードを取得するための API
HTTP POST
application/x-www-form-urlencoded
トークンエンドポイントがクライアント認証を必要とする場合、このエンドポイントもクライアント認証を必要とする
認可リクエストのパラメーターも受け付ける
- web の文脈でしか意味がないパラメーターもあるけど意味ない
レスポンスは認可コードかエラーコード
- このエンドポイントを今後叩く際に使う auth_session も含むことがある

inabajunmr

5. Authorization Initiation

クライアントはユーザーに identifier やその他のアカウント情報の入力を促すことで認可フローを開始したい場合がある。authorization challenge endpoint はこの login hint を収集し、クライアントを次のステップ（MFA flow や OAuth のリダイレクトベースのフロー）に導く。

セキュリティを担保するため、認可サーバーは認証フローの開始前にクライアントのファーストパーティ性を検証しなければならない。

inabajunmr

5.1. Authorization Challenge Request

client_id
scope
acr_values
auth_session
任意の拡張

inabajunmr

5.2. Authorization Challenge Response

認可サーバーはこの時点で渡された情報が認可コードの発行に十分かどうかを決定し、十分であれば認可コードを返す。もし情報が十分でなければエラーレスポンスを返す。

5.2.1. Authorization Code Response

認可コードを返せる場合 authorization_code を返す。

5.2.2. Redirect Response

認可サーバーがユーザーとのインタラクションを直接することを要求する場合、redirect レスポンスを返す。認可サーバーはリスク評価やアプリケーションが未実装の認証メソッド、アカウントリカバリーなどの例外フローをハンドルするのにユーザーと直接のインタラクションを選択する。

inabajunmr

redirect response の場合のレスポンスは redirect パラメーターを PAR の形式で返す

inabajunmr

5.2.3. Error Response

エラー系いろいろ
クライアントがユーザーを認証するためのアクションがわかるようなエラーを返す必要がある
auth_session クライアントによる後続のリクエストと関連付けさせる

inabajunmr

5.3. Auth Session

同一のクライアントからの後続のリクエストを関連付けさせるため認可サーバーが発行する

inabajunmr

トークンエンドポイントのレスポンスでも auth_session が来る。これはまた authorization challenge endpoint を叩くときに指定する

inabajunmr

セッションとして認証済みで期限切れじゃなかったらそれだけで認証済みにする、とかしてもいいのかな

inabajunmr

エラーレスポンスの場合も auth_session がくる
再認証必要だけど最初よりは要素少なくてよい、みたいなやつかな

inabajunmr

なんとなくの流れ

MFA の場合

Client -> AZ(Authorization Challenge Endpoint)
- username : xyz で認可したいですよろしく
AZ -> Client
- パスワードくれ
- username : xyz の auth_session は aaa な
Client -> AZ(Authorization Challenge Endpoint)
- auth_session : aaa
- password : p@ssw0rd
AZ -> Client
- TOTP もくれ
- auth_session は bbb な
  - 変えなくても良さそう？
Client -> AZ(Authorization Challenge Endpoint)
- auth_session : bbb
- TOTP : 0123456
AZ -> Client
- 認可コードやるよ

passkey の場合

Client -> AZ(Authorization Challenge Endpoint)
- username : xyz で認可したいですよろしく
AZ -> Client
- パスキーでよろしく
- username : xyz の auth_session は aaa な
Client -> AZ(Authorization Challenge Endpoint)
- auth_session : aaa
- Client でパスキーの認証セレモニー終わったので署名済みチャレンジを渡します
AZ -> Client
- 認可コードやるよ

インタラクションを必要とする場合

Client -> AZ(Authorization Challenge Endpoint)
- username : xyz で認可したいですよろしく
AZ -> Client
- こいつアカウントロックしてるから IdP での作業必要だわ
- redirect URI 渡すからそこに遷移させてくれ
Client
- もらった URI にリダイレクト
AZ
- ユーザーから認可リクエストがくる

このスクラップは2023/10/23にクローズされました