【図解】OAuth 2.0の認可コードフローとは？PKCE・state・リダイレクトURIの役割をEntra IDのリクエスト例で初心者向けに解説

OAuth 2.0 の記事では、全体像をつかむために、認可コードの流れを大まかな図にしました。ただ、実際にアプリ登録をしたり、サインインがうまくいかないときにブラウザの通信を見たりすると、URL に state や code_challenge のような見慣れないパラメータがたくさん並んでいます。この記事では、認可コードフローを一歩ずつ分けて、それぞれのパラメータが何のためにあるのかを、RFC と Microsoft（Entra ID）のリクエスト例で確かめながら図にしました。

この記事でわかること
  1. 認可コードフローの5つの手順と、ブラウザ経由・アプリから直接の分かれ目
  2. 認可リクエストのパラメータ（client_id・redirect_uri・scope・state・code_challenge）の役目
  3. 認可コードは「期限が短く、一度しか使えない引換券」であること
  4. PKCE：コードを頼んだアプリと、引き換えに来たアプリが同じかを確かめるしくみ
  5. Web アプリ・SPA・スマホアプリでの違い

まずはたとえで：クロークの引換券

認可コードフローは、クロークの引換券に似ています。受付カウンターで「預けます」と言うと、品物の代わりに番号の書いた引換券が渡されます。品物は、受け取り窓口で引換券を見せたときに初めて受け取れます。

あなた受付カウンター（認可エンドポイント）「預けます」と許可No.57引換券（認可コード）アプリ受け取る受け取り窓口（トークンエンドポイント）券と本人確認を見る品物（アクセストークン）・引換券そのものは品物ではない（コードはトークンではない）・引換券は期限が短く、一度しか使えない・受け取るときは、券のほかに本人確認（アプリの証明・PKCE）も要る
図1　認可コードは「引換券」、アクセストークンは「品物」

認可コードフローでは、受付カウンターが認可エンドポイント、引換券が認可コード、受け取り窓口がトークンエンドポイント、品物がアクセストークンです。いきなりトークンを渡さずに、いったん引換券を挟むのがこの方式の特徴です。

引換券を挟む理由は、受け渡しの道が2つに分かれているからです。認可コードは、ブラウザを通ってアプリに届きます。ブラウザを通る道は、アプリの外を通る道で、アプリからは守りきれません。そこで、ブラウザには期限が短く一度しか使えない引換券だけを通し、大事なトークンは、アプリがトークンエンドポイントから直接受け取ります。

全体の流れ：5つの手順

RFC 6749 は、認可コードフローを (A)〜(E) の5つの手順で説明しています。それぞれの矢印に、実際に送られるパラメータを書き込むと次のようになります。

認可サーバ人ブラウザアプリクライアント認可エンドポイントトークンエンドポイントAPIGraph など(A) 案内(A) GET /authorizeclient_id redirect_uri scopestate code_challenge(B) サインインして同意(C) redirect_uri へ戻すcode stateアプリに届くstate を照合(D) POST /tokencode redirect_uri code_verifier＋アプリの証明(E) コード・リダイレクト URI・アプリ・PKCE を確かめるアクセストークン（＋リフレッシュ・ID）Authorization: Bearer で API を呼ぶ前半（A〜C）はブラウザ経由、後半（D・E）はアプリから直接
図2　認可コードフローの5つの手順と、送られるパラメータ
手順何をするか（RFC 6749）通り道
(A)アプリが、利用者のブラウザを認可エンドポイントへ案内するブラウザ経由
(B)認可サーバが、ブラウザを通して利用者を確かめ（サインイン）、許可するかを聞く（同意）ブラウザ経由
(C)利用者が許可すると、認可サーバはブラウザをアプリへ戻す。そのとき認可コードを付けるブラウザ経由
(D)アプリが、認可コードを付けてトークンエンドポイントにトークンを頼むアプリから直接
(E)認可サーバが、アプリと認可コードを確かめ、リダイレクト URI が (C) と同じかも確かめて、アクセストークンを返すアプリから直接

ここからは、Microsoft のドキュメントにある Entra ID の例で、手順ごとに中身を見ていきます。この例では、アプリが利用者のメールを読む許可（mail.read）を求めています。

手順ごとに見る

認可リクエストを送る（A）

アプリは、次のような URL を組み立てて、利用者のブラウザをそこへ移動させます（リダイレクト）。見やすさのために改行してありますが、実際は1本の URL です。

認可リクエストの例（Microsoft のドキュメントより）

// Line breaks for legibility only

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&state=12345
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
認可リクエストの中身/{tenant}/oauth2/v2.0/authorize宛先Entra ID の認可エンドポイントclient_id=…どのアプリかアプリ登録で割り当てられた IDresponse_type=code何を返すか認可コードを返してほしいredirect_uri=…どこへ返すか登録したリダイレクト URI と完全に一致scope=…何を許してほしいか例：メールを読む（mail.read）state=12345戻りの照合用アプリが作ったランダムな値code_challenge=…PKCE の片割れcode_verifier から作った値（S256）アプリは、これらを URL に付けて、ブラウザを認可エンドポイントへ移動させる
図3　認可リクエストの中身
パラメータ意味
tenantURL の中の {tenant}。誰がサインインできるかを決める。common、organizations、consumers、テナント ID など
client_idアプリ登録で割り当てられたアプリの ID
response_type=code認可コードを返してほしい、という意味。認可コードフローでは code を含める
redirect_uri認可コードを返してほしい先。アプリ登録で登録したリダイレクト URI のどれかと完全に一致している必要がある（URL エンコードして送る）
scope利用者に同意してほしい範囲。スペースで区切って並べる
response_mode結果の返し方。query なら、リダイレクト URI の後ろに付けて返す
stateアプリが作った値。結果と一緒に同じ値が返ってくるので、アプリはそれを照合する
code_challengePKCE の値。アプリが手元に持つ code_verifier から計算したもの
code_challenge_method計算の方法。S256（SHA-256）を使う

リダイレクト URI を完全一致で確かめるのは、認可コードを決まった場所にしか返さないためです。OAuth 2.0 のセキュリティのベストプラクティス（RFC 9700）も、認可サーバはリダイレクト URI を文字列の完全一致で比べるよう求めています。

サインインと同意（B）

ブラウザが認可エンドポイントに着くと、ここから先は認可サーバの画面です。アプリはこの間、何もしません。利用者のパスワードにも触れません。

/authorizeサインイン済み？はい求めた範囲に同意済み？はいコードを出すいいえサインイン画面（MFA などもここ）いいえ同意画面管理者しか同意できない許可は利用者に同意できない旨のエラー
図4　(B) で認可サーバが確かめること（Microsoft の場合）
  • サインイン：まだサインインしていなければ、サインイン画面を出します。多要素認証などもここで行われます。
  • 同意：利用者が scope の範囲にまだ同意していなければ、同意画面を出します。
  • 管理者しか同意できない許可：組織のディレクトリに書き込む許可（Directory.ReadWrite.All など）は、利用者が同意できません。利用者には、同意できない旨のエラーが表示されます。

認可コードと state が戻ってくる（C）

利用者がサインインして同意すると、認可サーバはブラウザを redirect_uri へ戻します。response_mode=query なら、URL の後ろに認可コードと state が付いてきます。

認可コードが返ってきたときの例（Microsoft のドキュメントより）

GET http://localhost?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345
パラメータ意味
code認可コード（引換券）。Microsoft の場合、期限はふつう1分ほど。RFC 6749 も、すぐに期限切れにすること（最長10分を推奨）と、一度しか使えないことを決めている
state(A) で送った値と同じものが返る。アプリは同じかを確かめる

state は、アプリが「自分が始めたサインインの戻りか」を確かめるための値です。RFC 6749 は、state をクロスサイトリクエストフォージェリ（CSRF）を防ぐために使うよう勧めています。Microsoft も、ランダムでほかと重ならない値を使うのが一般的だと書いています。

アプリ(A) の前ランダムな state を作り、自分の側に覚えておくstate=8fJq2…URL に付ける(C) で戻ってきたとき戻ってきた state と、覚えておいた値を比べる同じ→ 続ける違う・ない→ 捨てる自分が始めたサインインの戻りかどうかを、state で確かめる
図5　state で、自分が始めたサインインの戻りかを確かめる

Microsoft は、state に URL などの機密になりうるデータをそのまま入れないよう注意しています。戻ったあとに使いたい情報があるときは、アプリの側に保存しておき、state にはその保存場所を指すキーだけを入れます。

コードをトークンに引き換える（D）

認可コードを受け取ったアプリは、トークンエンドポイントへ直接 POST します。ここはブラウザを通らず、アプリ（Web アプリならサーバ）から送ります。

トークンの要求の例（Microsoft のドキュメントより。シークレットを使う Web アプリの場合）

// Line breaks for legibility only

POST /{tenant}/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=11112222-bbbb-3333-cccc-4444dddd5555
&scope=https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 
&client_secret=sampleCredentia1s    // NOTE: Only required for web apps. This secret needs to be URL-Encoded.
パラメータ意味
grant_typeauthorization_code。認可コードで引き換える、という意味
code(C) で受け取った認可コード
redirect_uri(A) で送ったものと同じ値。RFC 6749 は、(A) で送ったなら (D) でも送り、値が同じであることを求めている
code_verifierPKCE の元の値。(A) の code_challenge はこれから計算したもの
client_secretアプリ自身の証明。サーバで秘密を安全に持てる Web アプリだけが使う。SPA やスマホアプリでは使わない

アプリ自身の証明には、シークレットの代わりに証明書も使えます。その場合は client_secret の代わりに、証明書で署名した値（client_assertion）を送ります。Microsoft は、より安全な証明書を使うことを勧めています。

アプリ(D)トークンエンドポイントの確認1. コード本物で、期限内で、まだ使われていないか2. リダイレクト URI(A) で送った値と同じか3. アプリの証明シークレットや証明書（機密クライアント）4. PKCEverifier から計算した値が、(A) の challenge と同じか全部 OKトークンを出すどれか NGエラーinvalid_grant などコードを2回使おうとすると断られ、それまでのトークンも取り消されることがある
図6　トークンエンドポイントが確かめること

トークンエンドポイントは、図6の4つをすべて確かめてからトークンを出します。RFC 6749 は、同じ認可コードを2回使おうとしたら断ること、できればそのコードで出したトークンも取り消すことを求めています。

トークンが届く（E）

トークンが返ってきたときの例（Microsoft のドキュメントより）

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "scope": "https%3A%2F%2Fgraph.microsoft.com%2Fmail.read",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
項目意味
access_tokenAPI を呼ぶためのアクセストークン
token_typeトークンの種類。Entra ID は Bearer だけ
expires_inアクセストークンの有効な秒数（この例では 3599 秒、約1時間）
scopeこのアクセストークンで許された範囲
refresh_tokenアクセストークンを取り直すためのトークン。範囲に offline_access を入れたときだけ届く
id_token誰がサインインしたかを表す ID トークン。範囲に openid を入れたときだけ届く

アプリは、アクセストークンを Authorization: Bearer ヘッダに付けて API を呼びます。ここから先は、OAuth 2.0 の記事で見た Bearer トークンの使い方と同じです。

PKCE：コードを頼んだアプリが、引き換えに来たかを確かめる

PKCE（Proof Key for Code Exchange）は、RFC 7636 で決められた、認可コードフローに足す守りです。RFC 7636 は、シークレットを持てない公開クライアント（スマホアプリなど）が、ブラウザやリダイレクトの途中で認可コードを横取りされる攻撃を受けやすいことを、PKCE が必要な理由に挙げています。

PKCE がないとPKCE があると認可コードブラウザやリダイレクトを通って届く本来のアプリコードを手に入れた別のアプリトークンエンドポイントコードコードだけシークレットのないアプリは区別しにくい認可コードブラウザやリダイレクトを通って届く本来のアプリコードを手に入れた別のアプリトークンエンドポイントコード＋verifierコードだけverifier がないので断る× コードだけで引き換えられてしまうおそれ◯ 最初に頼んだアプリだけが引き換えられるPKCE は「コードを頼んだアプリ」と「引き換えに来たアプリ」が同じかを確かめる
図7　PKCE がない場合とある場合

認可コードはブラウザやリダイレクトを通って届くので、本来のアプリ以外の手に渡る可能性をゼロにはできません。Web アプリならシークレットでアプリを確かめられますが、シークレットを持てないアプリでは、コードを持ってきた相手が本物かを区別しにくくなります。PKCE を使うと、最初にコードを頼んだアプリしか知らない値を持っていなければ、コードを引き換えられなくなります。

PKCE のしくみ

認可サーバ（同じサーバの2つの窓口）アプリverifier を手元に保管認可エンドポイントトークンエンドポイント① ランダムな code_verifierを作る（43〜128 文字）② SHA-256 → Base64URL でcode_challenge を作る③ /authorize（code_challenge・S256）④ 認可コードを作り、challenge を結び付ける記録コード ↔ challenge⑤ 認可コード⑥ /token（認可コード ＋ code_verifier）コードから取り出す⑦ コードに結び付いた challenge と、verifier から計算し直した値を比べる⑧ 一致すればトークンchallenge を受け取るのは認可エンドポイントだけ。トークンエンドポイントは、認可コードを手がかりに同じ記録を見る先に見せるのは計算結果（challenge）、後で見せるのは元の値（verifier）
図8　PKCE の流れ
  1. ①② アプリは、毎回ランダムな code_verifier を作って手元に保管し、そこから code_challenge を計算します。code_verifier は 43〜128 文字の、推測できないランダムな文字列です。
  2. ③④ 認可リクエストでは、計算した結果の code_challenge だけを、認可エンドポイントに送ります。認可サーバは認可コードを作るときに、受け取った code_challenge と計算の方法（S256）を、その認可コードに結び付けて記録します。
  3. ⑤ 認可コードがアプリに返ります。
  4. ⑥⑦ トークンの要求では、認可コードと一緒に、元の値の code_verifier をトークンエンドポイントに送ります。認可サーバは、届いた認可コードに結び付けておいた code_challenge を取り出し、code_verifier から計算し直した値と同じかを確かめます。

challenge を送っていないトークンエンドポイントで、なぜ比べられるのか

code_challenge を受け取るのは、認可エンドポイントだけです。それでもトークンエンドポイントで比べられるのは、2つの窓口が同じ認可サーバの窓口だからです。認可サーバは④で、code_challenge を認可コードに結び付けて記録しておきます。⑥で認可コードが届くと、そのコードを手がかりに、結び付けておいた code_challenge を探せます。認可コードが、「どの challenge と比べればよいか」を指す目印になっているわけです。

RFC 7636 は、記録の持ち方として2つを挙げています。よくあるのは、code_challenge を暗号化して、認可コードそのものの中に入れておくやり方です。もう1つは、認可サーバの中に「コードと challenge の対応」を保存しておくやり方です。どちらでも、アプリから見たしくみは変わりません。

先に見せるのは計算結果、後で見せるのは元の値、というのがポイントです。ただし、⑥でも code_verifier を送っているので、「結局どこかで見えてしまうのでは？」と思うかもしれません。ここで大事なのは、2つの値が通る道の違いです。

ブラウザ・リダイレクト経由の道（③⑤）横取りされうるアプリブラウザ・端末の中の受け渡し認可エンドポイント③ code_challenge →← ⑤ 認可コードここで見えうるのは、計算結果と引換券だけアプリから直接の道（⑥）TLS で守るアプリトークンエンドポイント⑥ 認可コード＋ code_verifier →元の値は、この道でしか送らない・S256 なら、challenge から verifier は計算できない・verifier は毎回作り直し、認可コードは一度しか使えない・アプリそのものが乗っ取られた場合などは、PKCE では守れない
図9　code_challenge と code_verifier は、通る道が違う
  • ブラウザ・リダイレクト経由の道（③⑤）：RFC 7636 が心配しているのは、この道です。認可コードは、ブラウザや、端末の中でのアプリどうしの受け渡しを通ってアプリに届きます。RFC 7636 はこれを「TLS で守られていない通り道」と書いています。同じリダイレクト先を複数のアプリが登録できてしまう端末では、別のアプリにコードが届くおそれもあります。この道を通るのは、計算結果の code_challenge と、引換券の認可コードだけです。
  • アプリから直接の道（⑥）：元の値の code_verifier は、ブラウザを通らず、アプリから認可サーバのトークンエンドポイントへ直接送ります。RFC 6749 は、トークンエンドポイントへのリクエストに TLS を求めています。RFC 7636 も、code_verifier は TLS で送られるので横取りされない、という前提に立っています。

つまり、横取りされうる道には「計算結果」と「引換券」しか流さず、「元の値」は守られた別の道でしか流さないように分けているのです。SHA-256 の計算結果から元の値を求めることはできないので、③⑤の道で code_challenge や認可コードが見えても、code_verifier は分かりません。

さらに、code_verifier は認可リクエストのたびに新しく作り、認可コードは一度しか使えません。⑥で引き換えた時点でそのコードは使い終わるので、組み合わせて使い回すこともできません。

一方で、PKCE で守れない場面もあります。RFC 7636 は、PKCE の安全性は「code_verifier を攻撃者に知られない、推測されないこと」に頼っていると書いています。アプリそのものが乗っ取られた場合や、TLS が破られた場合は、PKCE では守れません。PKCE が守るのは、あくまで③⑤の道です。RFC 7636 が、code_verifier を推測されにくい十分な長さのランダムな値（256 ビット以上のエントロピー）で作るよう勧めているのも、このためです。

S256 の計算は、「code_verifier を SHA-256 にかけ、その結果を Base64URL で文字列にする」です。RFC 7636 の付録にある例の値で、実際に計算してみました。RFC に書かれている code_challenge と同じ値になります。

RFC 7636 の例の code_verifier から code_challenge を計算した結果

$ python3 -c "import hashlib, base64; v='dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk'; print(base64.urlsafe_b64encode(hashlib.sha256(v.encode()).digest()).rstrip(b'=').decode())"
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
S256 と plain

RFC 7636 には、計算しないでそのまま送る plain という方法もあります。ただし RFC 7636 は、S256 を使えるクライアントは S256 を使わなければならないとしています。plain だと、code_challenge がそのまま code_verifier になってしまうからです。RFC 7636 は、③の認可リクエストの中身まで見られてしまう場合も考えています。そのときでも、S256 なら見えるのは計算結果だけですが、plain では元の値が見えてしまい、守りになりません。

PKCE はもともと公開クライアントのために作られましたが、今はすべてのアプリで使うのが標準です。RFC 9700 は、公開クライアントには PKCE を必須、機密クライアントにも推奨としています。Microsoft も、すべての種類のアプリに PKCE を勧め、SPA では必須にしています。

アプリの種類による違い

認可コードフローは、Web アプリ・SPA（ブラウザだけで動くアプリ）・デスクトップやスマホのアプリで使えます。違いが出るのは、アプリ自身の証明と、リダイレクト URI です。

SPA とは

SPA（シングルページアプリケーション）は、最初に1回だけページを読み込み、あとはブラウザの中で動く JavaScript が API からデータを取って、画面の一部だけを書き換える Web アプリです。Microsoft のドキュメントでは、主に JavaScript で書かれ、Angular・React・Vue などのフレームワークを使うことが多いと説明されています。プログラムがすべて利用者のブラウザの中で動くので、Microsoft は SPA を、秘密を安全に保存できない公開クライアントとして扱います。

Web アプリサーバで動く種類機密クライアントアプリの証明シークレット・証明書（証明書を推奨）PKCE推奨リダイレクト URI登録したアプリの URLSPAブラウザで動く種類公開クライアントアプリの証明持たない（ブラウザに置けない）PKCE必須（Microsoft）リダイレクト URI種類を spa にして登録デスクトップ・スマホ端末で動く種類公開クライアントアプリの証明持たない（端末に安全に置けない）PKCE使う（RFC 9700 で必須）リダイレクト URIhttp://localhost などシークレットを安全に置ける場所があるかどうかで、アプリの証明の方法が変わる
図10　アプリの種類ごとの違い（Microsoft の場合）
アプリアプリ自身の証明そのほかの注意
Web アプリ（サーバで動く）シークレットか証明書をサーバに置く。Microsoft は証明書を推奨。PKCE も推奨(D) はサーバから送る
SPA（ブラウザで動く）シークレットも証明書も使わない。ブラウザの中に安全に置けないためMicrosoft では PKCE が必須。リダイレクト URI の種類を spa にして登録する。spa の種類にしないと、ブラウザからトークンエンドポイントを呼ぶときに CORS のエラーになる。リフレッシュトークンの期限は24時間
デスクトップ・スマホシークレットも証明書も使わない。端末に安全に置けないためPKCE を使う。Microsoft は、システムのブラウザを使うアプリのリダイレクト URI に http://localhost を勧めている

うまくいかないとき

Microsoft のドキュメントに載っているエラーのうち、よく出会いそうなものです。

エラー意味確かめること
access_denied(C) で返る。利用者が同意しなかった、またはサインインをやめた同意しないと先に進めないことを利用者に伝える
invalid_grant(E) で返る。認可コードか code_verifier が正しくない、または期限切れ(A) からやり直す。code_verifier が (A) のときのものと同じか
invalid_client(E) で返る。アプリの証明に失敗したシークレットや証明書が正しいか、期限が切れていないか
invalid_scope範囲の指定が正しくないscope の値
consent_required
interaction_required		同意や、追加の操作（多要素認証など）が必要/authorize から、画面を出してやり直す
CORS のエラーSPA で、ブラウザからトークンエンドポイントを呼べないリダイレクト URI の種類が spa になっているか

企業での例

場面アプリの種類押さえどころ
社内の申請システムに Entra ID でサインインし、本人のメールや予定も読むWeb アプリ（機密クライアント）証明書でアプリを証明し、PKCE も付ける。リダイレクト URI は本番の URL だけを登録する
ブラウザだけで動く社内ダッシュボードから API を呼ぶSPA（公開クライアント）シークレットは持たない。リダイレクト URI を spa にして、PKCE で守る
現場で使うスマホの業務アプリスマホアプリ（公開クライアント）シークレットは持たない。PKCE を必ず使う

まとめ

項目内容
たとえ認可コードは引換券、アクセストークンは品物。ブラウザには引換券だけを通す
5つの手順(A) 認可リクエスト → (B) サインインと同意 → (C) コードが戻る → (D) コードを引き換える → (E) トークンが届く。A〜C はブラウザ経由、D・E はアプリから直接
redirect_uri登録した値と完全一致。(A) と (D) で同じ値を送る
stateアプリが作ったランダムな値。戻ってきたら同じかを照合する
認可コード期限が短く（Entra ID はふつう約1分）、一度しか使えない
PKCE先に code_challenge（計算結果）を認可エンドポイントへ、後で code_verifier（元の値）をトークンエンドポイントへ見せる。認可サーバは challenge を認可コードに結び付けて記録し、引き換えのときに比べる。S256 を使う。今はすべてのアプリで使う
アプリの種類サーバで動く Web アプリだけがシークレットや証明書を持つ。SPA とスマホアプリは持たない

参考にした資料

この記事は、次の標準と公式ドキュメントで内容を確かめて書きました。仕様や対応状況は変わることがあるので、最新の情報はリンク先で確かめてください。

あとがき

認可コードフローは、URL に並ぶパラメータの多さで身構えてしまいますが、ひとつずつ見ると「どのアプリか」「どこへ返すか」「何を許すか」「自分の戻りか」「頼んだ本人か」を確かめているだけでした。特に PKCE は、RFC の例の値で実際に計算して一致したのを見て、「先に計算結果、後で元の値」という発想がすっと入ってきました。サインインのトラブルでブラウザの通信を見るときも、この順番を知っていると、どこで止まっているのか見当をつけやすくなりそうです。

関連記事：OAuth 2.0とは？／セッションとトークンの違い／APIの認証方式とは？／認証と認可の違い／暗号の基礎

コメント