Authorization ServerがアクセストークンをURL経由でブラウザへ直接返します。実装は単純ですがトークンがブラウザに露出するため、現在の新規アプリでは利用しません。
はじめに / 全体の流れ
このフローで、
何をするの？
このフローのゴール
以前のブラウザアプリが、コード交換をせずアクセストークンを受け取る仕組みを理解します。
受付から入館証を封筒に入れず、人が多い通路で直接手渡すようなものです。現在は安全な受け渡し場所で交換する方式を使います。
歴史的な動作とリスクを理解し、Authorization Code + PKCEへ移行すべき理由が分かります。
登場人物
図では、縦の列ごとに担当者やシステムを分けています。
Operator
処理を開始する人や運用システムです。フローによっては途中から登場しません。
Client
ユーザーに代わって認可を依頼し、許可されたAPIを呼び出すアプリです。
Authorization
ログイン、同意、コードやトークンの発行を担当する信頼できるサーバーです。
Resource
アクセストークンを確認して、許可されたデータや機能を提供するAPIです。
図の読み方: 光る丸が今説明している通信です。自動再生を止めたいときは「Pause」を押し、気になる矢印を選んでください。
OOperatorResource Owner
CClientApplication
AAuthorizationToken Service
RResourceProtected API
01
Operator → Client
ログイン開始
このステップで行うことブラウザアプリが認可を開始します。
REQUEST / RESPONSE EXAMPLEBrowser → Authorization Server
REQUEST
POST /login
Content-Type: application/x-www-form-urlencoded
username=user&password=********レスポンス
HTTP/1.1 302 Found
Location: https://client.example/api/auth/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj
Cache-Control: no-store値の引き継ぎ: Authorization Serverがcodeを新しく発行し、Locationのクエリへ入れます。stateは最初の認可リクエストでClientが送った値を、そのまま返したものです。ブラウザはこのLocationへ自動的に移動するため、次のステップでは同じcodeとstateを持つGETリクエストが発生します。
※ トークン、challenge、Credential IDなどは説明用に短縮したサンプル値です。
Related flows