印刷アプリに写真サービスのパスワードを渡さず、「写真を読む」ことだけを任せる仕組み OAuth。認可コードフローと PKCE を1歩ずつ動かし、引換券とトークンの行き先、state と redirect_uri の役目までを図で追います。
前の章では、署名つきのトークン JWT の形を見ました。この章では、トークンを「誰が、どうやって手に入れるのか」を決める仕組み OAuth（オーオース）を扱います。第1章の言葉でいえば、認証ではなく認可の話です。
アオイは写真サービスに旅行の写真をためていて、その何枚かを別の会社の印刷アプリで注文したいと考えました。写真を読むには写真サービスにログインする必要があります。OAuth が広まる前は、図のように印刷アプリへ写真サービスのパスワードをそのまま渡し、アプリがアオイとしてログインするやり方がよく見られました。
これには困ったことが三つあります。一つ目は、アプリが何でもできてしまうことです。写真を読むだけのつもりでも、パスワードがあれば削除も設定の変更もできます。二つ目は、取り消しにくいことです。印刷アプリだけを締め出すにはパスワードを変えるしかなく、ほかに使っているアプリまで巻き込みます。三つ目は、パスワードが漏れる場所が増えることです。印刷アプリに保存されたパスワードが盗まれれば、アカウントごと乗っ取られます。
OAuth は、パスワードを渡す代わりに、範囲を絞ったアクセスの権利だけをアプリに「委ねる」仕組みです。図では、印刷アプリが持っていたパスワードがアオイの手元に戻り、代わりにオレンジ色の アクセストークン が印刷アプリに渡っています。アクセストークンは「このアプリは、アオイの写真を読んでよい」という許可を表す値で、写真サービスが発行します。下の赤い札も、緑の札に変わりました。
ホテルのカードキーを思い浮かべると分かりやすいでしょう。フロントは客を確かめたうえで、その部屋だけが開き、チェックアウトの日には使えなくなるカードを渡します。マスターキーを貸すわけではありません。OAuth でも、写真サービスが利用者に確認してから、範囲（写真を読むだけ）と期限のついたトークンを発行します。いらなくなればトークンだけを無効にでき、パスワードを変える必要はありません。
ただし、たとえには限界もあります。カードキーは客が自分で受け取りますが、OAuth ではアオイがトークンを運ぶのではなく、写真サービスがアプリへ渡します。また、多くのアクセストークンは持っている人なら誰でも使える「持参人払い」の値で、写されると写した人も使えてしまいます。だから、トークンをどの道で運ぶかが、この章の大事な話になります。
OAuth には4つの役が出てきます。左上はアオイと、アオイが使うブラウザです。写真の持ち主なので、仕様では リソースオーナー（資源の持ち主）と呼ばれます。左下は印刷アプリで、アオイの代わりに写真を使いたい側です。OAuth ではこれを クライアント と呼びます。「サービスを呼び出す側のプログラム」という意味で、アオイのスマートフォンそのもののことではありません。
右上の 認可サーバー は、写真サービスの受付です。アオイのログインを確かめ、アオイの許可を記録し、トークンを発行します。右下の リソースサーバー は、写真そのものを返す写真 API です。トークンを見て、要求を通すかどうかを決めます。認可サーバーとリソースサーバーは、同じ会社の別々の部品であることがよくあります。
この4者の位置は、章の終わりまで変えません。上の段と左の縦の道はブラウザを通るやり取り、斜めと下の段は印刷アプリがほかのサーバーと直接話すやり取りになります。この区別が、あとで「なぜこういう手順なのか」を考える鍵になります。仕組みの全体は RFC 6749 に書かれています。
ここから、いま広く勧められている 認可コードフロー（Authorization Code Flow）に PKCE を組み合わせた手順 を1歩ずつ追います。アオイが印刷アプリの「写真サービスから読み込む」ボタンを押すと、印刷アプリは認可サーバーあての依頼を作り、ブラウザをそこへ向かわせます（リダイレクト）。依頼は URL の後ろに付く値として運ばれます。
白いカードが依頼の中身です。client_id は印刷アプリが写真サービスに登録したときにもらった名前、redirect_uri は用事が済んだらブラウザを戻してほしい先、scope は求める範囲です。ここでは「写真を読む」を表す photos:read だけを求めます（名前はこの章の例で、実際の名前はサービスごとに決まっています）。state は、この依頼に付けた使い捨ての合言葉で、役目はあとのページで説明します。
もう一つ、印刷アプリはその場で長いランダムな値 code_verifier を作り、自分の中にしまっておきます。依頼に付けて外へ出すのは、それを SHA-256 にかけた code_challenge だけです。第2章で見たとおり、ハッシュ値から元の値は戻せません。この仕掛けが PKCE（ピクシー）で、その効き目は④と⑤、そして後半のページで確かめます。
ブラウザが依頼を届けると、認可サーバーは依頼の中身を受け取って覚えておきます。図では白い依頼が認可サーバーのそばへ、灰色の code_challenge が認可サーバーの下へ移りました。認可サーバーは、client_id が登録済みのアプリか、redirect_uri がそのアプリに登録された戻り先と一致するかも確かめます。
続いて、アオイは写真サービスの画面でログインします。ここが OAuth の要です。アオイがパスワードを打ち込む先は写真サービス自身の画面で、印刷アプリの画面ではありません。パスワードは上の段の道を通って認可サーバーにだけ届き、印刷アプリはその値を一度も見ません。
ログインのあと、写真サービスは「印刷アプリが、あなたの写真の読み取りを求めています」という確認画面を出し、アオイは許可を押します。この許可が、緑のカードとして認可サーバーに記録されます。前に同じ許可をしたことがある場合などは、確認画面を省くサービスもあります。この時点で、印刷アプリはまだ何も受け取っていません。
アオイが許可すると、認可サーバーは 認可コード を発行します。図の黄色いカードです。認可サーバーはブラウザを、①で受け取って確かめた redirect_uri へ戻し、その URL に認可コードと、①で預かった state をそのまま付けます。ブラウザが戻り先を開くと、印刷アプリが認可コードを受け取ります。黄色いカードが上の段から左の縦の道を通って、印刷アプリの横まで来ました。
認可コードは、アクセストークンそのものではありません。「アオイが印刷アプリに写真の読み取りを許可した」という事実と結びついた、短命で一度しか使えない引換券です。これだけでは写真 API を呼べず、④で認可サーバーに持ち込んで初めてトークンと交換できます。期限は長くても10分ほどにすることが勧められています。
認可コードが通ってきたのは、ブラウザを通る道です。なぜ本物のトークンではなく引換券をこの道に通すのかは、手順を最後まで見てから考えます。
印刷アプリは、受け取った認可コードを認可サーバーの トークンエンドポイント に送ります。トークンエンドポイントは、トークンを発行するための専用の窓口です。図では、黄色い引換券と白い code_verifier が、斜めの道を認可サーバーへ向かっています。
この斜めの道はブラウザを通りません。印刷アプリが認可サーバーへ TLS で直接つなぎ、HTTP の POST で値を送ります。URL に値が載らないので、ブラウザの履歴やほかのページから見られることもありません。
送るのは、認可コード、①と同じ redirect_uri、client_id、そして①でしまっておいた code_verifier です。秘密の値を安全に持てるサーバー上のアプリなら、ここで client_secret などを使って「本物の印刷アプリです」という証明（クライアント認証）も一緒に送ります。スマートフォンのアプリやブラウザで動くアプリは、配ったプログラムから秘密を抜き出されるおそれがあるため、秘密を持たない前提で PKCE に頼ります。
認可サーバーは、受け取った値を一つずつ確かめます。認可コードが自分の発行したもので、期限内で、まだ使われていないこと。そのコードが同じ client_id のアプリに、同じ redirect_uri あてに出したものであること。そして PKCE の照合です。図の上のように、届いた code_verifier を SHA-256 にかけ、②で預かっていた code_challenge と同じ値になるかを比べます。
すべて通ると、認可コードは使い切りになり、図から消えます。代わりに認可サーバーは アクセストークン（オレンジ）を発行し、斜めの道で印刷アプリへ返します。多くの場合は リフレッシュトークン（灰色）も一緒に返します。応答には、トークンの種類（多くは Bearer）や有効期限の秒数も入っています。
ここで初めて、印刷アプリは写真を読むための値を手にしました。トークンはアオイのパスワードとは無関係に作られた値なので、あとからこのトークンだけを無効にすることもできます。
印刷アプリは写真 API を呼ぶとき、アクセストークンを HTTP の Authorization ヘッダーに「Bearer トークンの値」の形で付けます（RFC 6750）。Bearer は「持参人」という意味で、持って来た人に効き目がある値だということを表しています。図では、オレンジのカードが下の段を写真 API へ進みました。
写真 API は、トークンが有効か、期限が切れていないか、自分あてに出されたものか、どの範囲を許しているかを確かめます。このトークンの範囲は photos:read なので、写真の一覧や画像を読む要求は通します。一方、同じトークンで写真を消そうとしても、削除の範囲は許されていないので断ります。図の右の緑と赤の札がその結果です。
範囲のほかに、写真 API は「誰の写真か」も見ます。このトークンはアオイの許可から作られたので、読めるのはアオイの写真だけで、ほかの人の写真には届きません。灰色のリフレッシュトークンは印刷アプリに残ったままで、写真 API には見せません。
ここまでの流れは、遠回りに見えるかもしれません。認可サーバーは③で、いきなりアクセストークンをブラウザに渡せば済みそうです。わざわざ黄色い認可コードを一度渡し、④でトークンと引き換えさせるのには理由があります。
図の上の段と左の縦の道は、ブラウザを通る「表の道」です。ここを通る値は URL の一部として運ばれるので、ブラウザの履歴、サーバーのアクセスログ、ほかのページへ移るときに送られる参照元の情報などに残ることがあります。スマートフォンでは、別のアプリが同じ戻り先を名乗って値を横取りする手口も知られています。表の道は、盗み見られやすい道なのです。
そこで OAuth は、表の道には 短命で一度しか使えない引換券（認可コード） だけを通します。本物のアクセストークンは、斜めの「裏の道」、つまり印刷アプリと認可サーバーが TLS で直接つながったやり取りで受け取ります。仮に誰かが引換券を見ても、使える時間も回数もごく限られます。
ただ、限られるだけで、なくなるわけではありません。盗み見た人が先回りして引換券を交換してしまったら、どうなるでしょうか。それを防ぐのが次の PKCE です。
図では、盗み見る人が黄色い引換券を手に入れ、印刷アプリより先に認可サーバーへ持ち込もうとしています。PKCE（Proof Key for Code Exchange、RFC 7636）がなければ、引換券さえあれば交換できてしまう場面があります。
PKCE の鍵は、①で外へ出した code_challenge です。認可サーバーは交換のとき「その challenge の元になった値を見せてください」と求めます。code_verifier を知っているのは、それを作って手元にしまっておいた印刷アプリだけです。盗み見る人が見られたのは表の道を通った値、つまり challenge と引換券だけで、ハッシュ値から元の verifier を逆算することはできません。だから交換は拒否されます。
challenge の作り方として勧められているのは S256 です。verifier の SHA-256 ハッシュ値を、URL で使える文字（Base64url）で書き表したものが challenge になります。第2章のハッシュが、ここでは「元の値を明かさずに、あとで同じ値を持っていると示す」ために使われています。
PKCE が確かめるのは「依頼を出したのと同じアプリが交換に来た」ことで、「それが本物の印刷アプリか」ではありません。秘密を安全に持てるサーバー上のアプリなら、PKCE に加えてクライアント認証も行います。PKCE はクライアント認証の代わりにはなりません。
表の道には、盗み見のほかにもう一つ弱点があります。なりすます人が、自分のアカウントで取った認可コード入りの戻り先 URL を作り、アオイのブラウザに開かせる手口です。印刷アプリがそれを受け取ると、アオイの画面に相手の写真アカウントがつながり、アオイは気づかないまま相手のアカウントで操作してしまうおそれがあります。これは CSRF（クロスサイト・リクエスト・フォージェリ）と呼ばれる攻撃の一種です。
これを防ぐのが、①で付けた state です。印刷アプリは依頼のたびに推測できない値を作り、アオイのブラウザとひもづけて覚えておきます。左の縦の道を通って戻ってきた state が覚えた値と違えば、その応答は捨てます。PKCE にも同じ働きがありますが、state もあわせて使われることがよくあります。
図の右上は、戻り先そのものを狙う手口です。依頼の redirect_uri を自分のサイトに書き換えれば、引換券が自分のところへ届くと考えるわけです。認可サーバーは、アプリの登録時に決めた戻り先と文字列が完全に一致するときにだけ認可コードを返します。前方一致やワイルドカードのようなゆるい照合は抜け道になった例が多いため、RFC 9700 は厳密な一致を求めています。
⑤で受け取ったトークンは、行き先がはっきり分かれています。オレンジのアクセストークンは写真 API に見せるためのもので、寿命は数分から1時間ほどと短めにすることが多い値です。灰色のリフレッシュトークンは、アクセストークンの期限が切れたときに、新しいものを認可サーバーから出してもらうための値です。図では、期限の切れたアクセストークンが薄くなり、リフレッシュトークンが斜めの裏の道を通って認可サーバーへ向かっています。
リフレッシュトークンは写真 API には見せません。写真 API が受け取るのはアクセストークンだけです。寿命の長いリフレッシュトークンを見せる相手を認可サーバーだけに絞ることで、漏れたときの被害を小さくしています。リフレッシュトークンを出すかどうかは認可サーバーが決めます。ブラウザの中だけで動くアプリなどでは、使うたびに新しいリフレッシュトークンへ取り替える（ローテーション）といった守りも勧められています。
アクセストークンの中身にも決まった形はありません。第8章の JWT のように、写真 API が署名を確かめて中身を読める形のこともあれば、それ自体は意味を持たない文字列で、写真 API が認可サーバーに「この値は有効ですか」と問い合わせて初めて意味が分かる形（不透明なトークン）のこともあります。印刷アプリにとっては、どちらも中を読まずにそのまま見せる値です。
OAuth 2.0 の最初の仕様には、この章の手順のほかにも方式がありました。そのうち二つは、今では使わないよう勧められています。
一つは Implicit（インプリシット）フロー です。ブラウザの中だけで動くアプリのために、③で認可コードの代わりにアクセストークンそのものを URL に載せて返す方式でした。図の上の段のように本物のトークンが表の道を通るので、履歴やログからの漏れや差し替えを防ぎにくくなります。もう一つは Resource Owner Password Credentials で、図の左のようにアオイがパスワードを印刷アプリに打ち込み、アプリがそれをトークンと交換する方式です。章の最初に見た「パスワードを預ける」問題がそのまま残ります。
2025年に出た OAuth のセキュリティの指針 RFC 9700（OAuth 2.0 Security Best Current Practice）は、この二つを使わないこと、認可コードフローには PKCE を使うこと、redirect_uri を厳密に照合することなどをまとめています。
こうした改善を一つの仕様にまとめ直す OAuth 2.1 の取りまとめも、IETF で進んでいます。2026年11月の時点ではまだ草案（Internet-Draft）で、改訂が重ねられている段階です。新しく作るアプリは、この章の手順と RFC 9700 を出発点にすれば、OAuth 2.1 が目指す形とほぼ同じになります。
この章では、印刷アプリにパスワードを渡さず、「写真を読む」ことだけを任せる仕組みを追いました。アオイがパスワードを打つのは写真サービスの画面だけで、印刷アプリは三種類のカードを順に受け取ります。黄色い認可コードは表の道を一度だけ通る引換券、オレンジのアクセストークンは写真 API に見せる許可証、灰色のリフレッシュトークンは認可サーバーだけに見せて新しい許可証をもらうための券です。PKCE、state、redirect_uri の厳密な照合が、表の道の弱さを補っていました。
最後に一つ考えてみましょう。印刷アプリがアクセストークンを受け取ったら、「アオイがログインした」と考えてよいのでしょうか。答えは「いいえ」です。アクセストークンが表しているのは「この値を持つアプリに、写真を読む範囲で写真 API を使わせてよい」という委譲で、「いまこのアプリを使っているのはアオイで、いつ本人確認をした」という認証の結果ではありません。トークンは写真 API に向けた値で、印刷アプリに向けて誰かを証明する形にはなっていないのです。トークンを持っていることだけを根拠にログインさせると、別のアプリ向けに出たトークンを持ち込まれて、なりすまされるおそれもあります。
アプリに「誰がログインしたか」を標準の形で伝えるには、OAuth の上にもう一層が要ります。それが次章の OpenID Connect（OIDC）で、第8章の JWT が ID トークンとして再び登場します。
