Skip to content

MS_AuthCodeGrantFlowWithPKCE

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

Authorization Code Grant Flow with PKCE

概要

Implicit 非推奨に伴い、
SPAで PKCE する場合のプロファイル。

詳細

特徴

  • カスタム URL スキームを使用しない
    「response_mode=fragment」で認可リクエストを行う。

  • 従って、基本的には、ネイティブでやってた PKCE を、
    「response_mode=fragment」で、まんま SPA で
    実装すれば良い。

※ IdP が「response_mode=fragment」に対応している必要がある。

補足（response_mode の選択肢）: Authorization Code Flow の既定は
response_mode=query（?code=...）で、SPA でもこれは使える。
元ページが fragment（#code=...）を挙げているのは、
Implicit からの移行を念頭に置いているためと読める
（Implicit は fragment 固定なので、リダイレクト URI の登録や
フロントエンドの受け取り処理をそのまま流用できる）。
なお fragment はサーバやプロキシのログに残らないという利点もある
（OAuth 2.0 Threat Model (Access)を参照）。

実装

認証

  • PKCE なので、SPA からの
    Token リクエストでも、client_secret は不要。

  • JavaScript から基本認証の付加は難しいので、
    AuthZ(N) 側が
    client_secret_post を
    サポートしていると吉。
    （そもそも、client_secret 無しの基本認証ってのもアレ）

補足（Public Client なので client_secret は「持てない」）:
SPA は配布物の中身がすべて閲覧できるため、そもそも
client_secret を秘密にできない Public Client に分類される。
「不要」というより「持たせてはいけない」が正しく、
token_endpoint_auth_method は none を使う。
client_secret_post は Confidential Client 向けの方式である。

フロー

基本的に、ネイティブ・アプリケーションと同様に、
フロントエンド・ホスト側のエンドポイントは利用しなくていい。

  • 認可リクエストはフロントエンド・ホストからリダイレクトで開始するのだと
    考えていたが、

    • しかし、Router を定義した SPA では、自サイトに HTTP リクエストが飛ばず、
    • ネイティブ・アプリケーションと同様に、Public Client から直接リクエストした。

  • リダイレクト・エンドポイントを経由して Code を受け取るのだと考えていたが、

    • しかし、Router を定義した SPA では、自サイトに HTTP リクエストが飛ばず、
    • カスタム URL スキームと同様、直接、Public Client に戻って Code を取得する。

※ Router（URL によるページ遷移）を定義した
SPAでは、
　自サイトに HTTP リクエストが飛ばなくなる。と言うのがポイント。

補足（code_verifier はどこに置くか）: 上記のとおり
リダイレクトで戻ってきた先も同じブラウザ タブの JavaScript なので、
code_verifier と state は sessionStorage に置くのが一般的である
（localStorage はタブ／オリジンをまたいで残るため、
別タブの攻撃面が広がる）。
リダイレクトでページが再ロードされてもメモリ上の変数は消えるため、
「一時メモリに置く」だけでは動かない点に注意。

余談

バックエンドから client_secret 付きで Token リクエストにするものと
思っていたが、

  • 下記の「参考」を確認すると、client_secret は不要らしい
    （SPA 上から Token リクエスト可能）。

  • 一方で、Hybrid Flow の code は
    バックエンドから client_secret 付きで Token リクエスト
    （code_verifier 無いから）。

補足（現在の推奨は BFF）: 本ページの結論（SPA から直接
Token リクエストする）は当時の標準的な答えだったが、その後
「OAuth 2.0 for Browser-Based Apps」の
改版で、**トークンをブラウザに置かない BFF（Backend for Frontend）**が
第一の選択肢として整理された。
Web Storage 上のトークンは XSS 一発で抜かれるため、
トークンをサーバ側セッションに保持し、ブラウザには
HttpOnly Cookie だけを渡す構成が推奨されている。
「PKCE + SPA 直接」は BFF を置けない場合の次善策、という位置づけである。

参考

Okta Developer

Auth0

OSSコンソーシアム

開発基盤部会 Blog

本 Wiki 内

Tags: IT国際標準, 認証基盤, クレームベース認証, OAuth

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally