ユーザーはAuthorization Serverでログインし、クライアントへ渡してよい権限を選びます。クライアントは短時間有効な認可コードを受け取り、安全なバックチャネルでアクセストークンへ交換します。
はじめに / 全体の流れ
このフローで、
何をするの？
このフローのゴール
アプリへパスワードを渡さず、許可された範囲だけAPIを利用できるようにします。
ホテルの受付で本人確認を行い、部屋の鍵ではなく、許可された施設だけに入れる一時的なカードを受け取るイメージです。
クライアントはアクセストークンを使い、ユーザーが同意した範囲のAPIだけを呼び出せます。
登場人物
図では、縦の列ごとに担当者やシステムを分けています。
User
サービスを利用する人です。ログインや同意、端末の操作を行います。
Browser
WebサイトとAuthenticatorの間を安全につなぎ、WebAuthn APIを実行します。
Authenticator
秘密鍵を安全に保管し、生体認証やPINの確認と署名を行う端末機能です。
Relying Party
ユーザーをログインさせるWebサービスです。公開鍵を保存し、署名を検証します。
図の読み方: 光る丸が今説明している通信です。自動再生を止めたいときは「Pause」を押し、気になる矢印を選んでください。
UUserAuthorization Gesture
BBrowserWebAuthn Client
AAuthenticatorPlatform / Roaming
RRelying PartyApplication Server
01
User → Relying Party
第一要素でログイン
このステップで行うことユーザー名とパスワードなどの第一要素を検証します。
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