OpenID Connect Implicit Flow — Legacy

IDトークンやアクセストークンをAuthorization Endpointから直接返す旧OIDCフローです。現在はCode + PKCEを優先します。

Legacy flow — 新規実装では使用しないでください
StatusLegacy
Responseid_token token
ReplacementCode + PKCE

このフローで、
何をするの?

このフローのゴール

パスワードを送らずに、登録済みの端末を持つ本人だと証明します。

01まず全体像

Webサイトが一度だけ使える問題(challenge)を出し、Authenticatorが端末内の秘密鍵で答えに署名します。Webサイトは登録済みの公開鍵で署名を確認します。

02身近な例で考える

毎回違う書類へその場で印鑑を押し、Webサイトが登録済みの印影と照合するイメージです。過去の答えをコピーしても使えません。

03最後にどうなる?

署名、Webサイトの識別情報、challengeがすべて正しければ、ログイン済みセッションが発行されます。

登場人物

図では、縦の列ごとに担当者やシステムを分けています。

O
Operator

処理を開始する人や運用システムです。フローによっては途中から登場しません。

C
Client

ユーザーに代わって認可を依頼し、許可されたAPIを呼び出すアプリです。

A
Authorization

ログイン、同意、コードやトークンの発行を担当する信頼できるサーバーです。

R
Resource

アクセストークンを確認して、許可されたデータや機能を提供するAPIです。

図の読み方: 光る丸が今説明している通信です。自動再生を止めたいときは「Pause」を押し、気になる矢印を選んでください。

Interactive sequence
OOperatorResource Owner
CClientApplication
AAuthorizationToken Service
RResourceProtected API
01

Operator Client

サインイン開始

このステップで行うこと

ブラウザクライアントがnonceとstateを生成します。

なぜ必要?

このフローは互換性理解のためにのみ説明します。

このあと

次は「トークンを直接要求」へ進みます。

REQUEST / RESPONSE EXAMPLEBrowser → Relying Party
REQUEST
POST /webauthn/authentication/options
Content-Type: application/json
Accept: application/json
Cookie: session=...

{ "username": "user@example.com" }
レスポンス
HTTP/1.1 200 OK
Content-Type: application/json
Accept: application/json

{
  "challenge": "Y2hhbGxlbmdl...",
  "rpId": "example.com",
  "allowCredentials": [{ "type": "public-key", "id": "AbCdEf..." }],
  "userVerification": "required"
}

※ トークン、challenge、Credential IDなどは説明用に短縮したサンプル値です。

同じ仕様のフローを、続けて理解する。