Tech Learning Daily

登場人物とリダイレクトの全体像

OAuth 2.0(RFC 6749)には 4 つの役割がある。ログインしようとしている本人であるリソースオーナー、あなたが作った Web アプリであるクライアント、Google や GitHub 側の認可サーバー、そしてユーザーのデータを実際に持つリソースサーバーだ。認可コードフローでは、クライアントはまずユーザーのブラウザを認可サーバーの /authorize エンドポイントへresponse_type=code・client_id・redirect_uri・scope・state 付きでリダイレクトする。ユーザーが認可サーバー上でログインし同意すると、認可サーバーはあらかじめ登録された redirect_uri へ認可コード(短命で一度しか使えないランダムな文字列)を付けてブラウザを送り返す。

┌────────┐ ①/authorize ┌──────────┐
│ Browser │────────────▶│認可サーバー│
└────────┘             └──────────┘
     │②code(URLに乗る)      │
     ▼                      │
┌────────┐                  │
│ App     │③code→token(back)│
│(server) │◀─────────────────┘
└────────┘
     │④access token/id_token
     ▼
┌──────────────┐
│ リソースサーバー │
└──────────────┘

ここまでで手元にあるのはまだ「コード」だけであり、API を叩けるアクセストークンではない。次の一手が、このフローの設計で最も重要な部分になる。

なぜコードとトークンを分けるのか — フロントチャネルとバックチャネル

一見、認可コードをもらった時点でそのままログイン完了にしてしまえば早い。しかし認可コードはブラウザのリダイレクト(フロントチャネル)を経由して渡ってくる。URL はブラウザ履歴・プロキシのアクセスログ・Referer ヘッダーなど、TLS で暗号化された通信路の外側にも残りうる経路だ。ここに長生きするアクセストークンそのものを乗せてしまうと、漏洩したログ 1 行でアカウントを乗っ取られかねない。

そこで OAuth はもう一段階を挟む。クライアントのサーバーが受け取った認可コードを、今度はブラウザを介さずサーバー間の TLS 通信(バックチャネル)で認可サーバーの /token エンドポイントへ直接送り、client_secret(またはこの後説明する PKCE の証明)とセットで初めてアクセストークンと交換する。コードが URL に一瞬乗って見えたとしても、それを再利用するには「秘密」を追加で提示できないと成立しない。これが冒頭の問いへの答えだ — コードとトークンを分けているのは、経路の安全性が異なる 2 つの区間をまたぐからである。

この設計をさらに補強するのが state パラメータと redirect_uri の検証だ。state はクライアントが発行時に生成したランダム値で、コールバック時に同じ値が返ってくることを確認する。これがないと、攻撃者が自分のセッションの認可コードを被害者のブラウザに踏ませて「攻撃者のアカウントでログインした状態」を強制する CSRF が成立する。一方 redirect_uri は、認可サーバーが「事前に登録された値と完全一致するか」を照合する。一致確認がなければ、認可コードを攻撃者の管理するコールバック URL に横流しさせることができてしまう。state と redirect_uri 検証は守っている対象が別物であり、片方だけでは不十分だ。

秘密を持てないクライアントのための PKCE

SPA やモバイルアプリはコードがユーザーの端末上で動くため、client_secret をアプリに埋め込んでも解析されればすぐ漏れる。「秘密を安全に保管できないクライアント」向けに RFC 7636 が定義したのが PKCE(Proof Key for Code Exchange)だ。仕組みは client_secret の代わりに、リクエストごとに使い捨てる証明を作る。まず認可リクエストを送る前にランダムな code_verifier(43〜128 文字)をアプリ内だけで生成し、それを SHA-256 でハッシュして base64url エンコードした code_challenge を /authorize に送る。認可サーバーはこの challenge を認可コードと結びつけて記憶する。

# code_verifier を生成(実際の SDK もこれと同じ処理をしている)
VERIFIER=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=\n')

# S256 で code_challenge を導出
CHALLENGE=$(printf '%s' "$VERIFIER" | openssl dgst -sha256 -binary \
  | openssl base64 | tr -d '=\n' | tr '+/' '-_')

トークン交換のリクエストでは、challenge ではなく元の code_verifier を送る。認可サーバーは受け取った verifier を同じ手順でハッシュし、記憶しておいた challenge と一致するかを照合する。認可コードを横取りした攻撃者は challenge しか見ておらず、SHA-256 は一方向関数なので challenge から verifier を逆算できない。code_challenge_method には plain(verifier をそのまま challenge にする)も規格上は存在するが、これは challenge を見れば verifier がそのままわかってしまうため、制約の強い環境向けの後方互換にすぎず、通常は S256 を使う。

OAuth は認可、認証を足すのは OpenID Connect

ここまでの仕組みが守っているのは「このクライアントがこのユーザーの代わりに API を叩いてよいか」という認可(authorization)であり、「このユーザーは本当に本人か」という認証(authentication)ではない。RFC 6749 自体には身元情報を返す標準的な方法が定義されていない。ここに OpenID Connect(OIDC)が OAuth の上に ID Token という JWT を追加し、認証の役割を担わせる。

ID Token には iss(発行者)・sub(ユーザーを一意に指す識別子)・aud(想定するクライアントの client_id)・exp(有効期限)・iat(発行時刻)が必須クレームとして入っており、クライアントアプリはこれを検証して「誰がいつログインしたか」を確認する。一方のアクセストークンは API(リソースサーバー)側が「何をしてよいか」を判断するためのもので、JWT 形式のこともあれば意味を持たない不透明な文字列(opaque token)のこともある。同じレスポンスに両方入っていても、ID Token を読むのはクライアント、アクセストークンを読むのは API という受け手が違う。