認可のOAuthに認証を足す、薄いレイヤー

今日は手を止めて、OpenID Connect Core 1.0の仕様書（日本語版）を最初から読み込んだ。CodeNoteは今のところSupabase Authに認証をまかせていて、自前でOAuth/OIDCのフローを実装しているわけではない。ただ「認証」を扱うサービスである以上、いつかは向き合うことになる基礎知識だと思い、全体像を整理しておくことにした。

「認可」と「認証」は別物、という出発点

結論から言うと、OAuth 2.0とOpenID Connectは別物ではない。後者は前者の上に「認証」を足すための拡張だ。仕様書の冒頭にも、OpenID Connect 1.0は「OAuth 2.0プロトコルの上にシンプルなアイデンティティレイヤー（本人確認のための薄い層）を載せたもの」だと書かれている。

ポイントは、OAuth 2.0が扱うのは認可（Authorization）、OpenID Connectが足すのは認証（Authentication）だという点だ。

認可：「このアプリはあなたの代わりにこのリソースにアクセスしてよいか」という許可の話
認証：「今アクセスしてきているのは本当に誰なのか」という本人確認の話

空港に例えると、認証は「パスポートで本人確認をすること」、認可は「搭乗券でどの便に乗れる権限があるかを確認すること」にあたる。OAuth 2.0はもともと搭乗券（認可）の仕組みだけを定義していて、パスポート（認証）の部分は仕様の対象外だった。

ところがSNS連携ログインのようにOAuth 2.0が事実上の「ログイン機能」として使われることが増え、各サービスが独自解釈で認証っぽい使い方をしてしまい、仕様のズレが起きやすかった。OpenID ConnectはこのOAuth 2.0のフローの上に「ID Token」という検証可能な身分証明書を追加することで、認証の部分を標準化している。「権限を渡す」フローに「本人確認の結果を渡す」フローを足した、という理解でいったん納得した。

登場人物と用語を整理する

フローを追う前に、まず出てくる言葉を整理した。

OpenID Provider（OP）: End-Userを認証できるOAuth 2.0の認可サーバー。GoogleやAppleのログイン基盤などがこれにあたる
Relying Party（RP）: OPに認証とClaim（後述）を要求する側のクライアントアプリ
End-User: 実際にログインする人間
ID Token: 認証イベントに関する情報を含むJWT（署名付きのトークン）。OpenID Connectの中核的な成果物
Claim: ユーザーに関する情報の断片。名前・メールアドレスなど
UserInfo Endpoint: Access Tokenを提示すると、より詳しいユーザー情報（Claim）を返してくれるエンドポイント

ID Tokenが「認証済みであることの証明書」、UserInfo Endpointが「証明書だけでは足りない追加情報の取得窓口」という役割分担だと理解すると、以降のフローの説明が読みやすくなった。

3つの認証フロー

仕様書ではAuthorization Requestのresponse_typeパラメータによって、3種類のフローが定義されている。違いを一言でまとめると、「トークンをどの経路で、いつ受け取るか」の違いだ。

Authorization Code Flow（`response_type=code`）

RPはまずAuthorization CodeというワンタイムのコードだけをAuthorization Endpointから受け取る。そのコードをToken Endpointに渡し、ID TokenとAccess Tokenに交換する。トークン自体がブラウザ（User Agent）を経由しないため、フロントチャネル（ブラウザを経由する、ユーザーの目に触れうる経路）に露出しないのが最大の特徴だ。Client Secretを安全に保管できるサーバーサイドWebアプリケーション向けで、3つの中で最も安全とされている。Refresh Tokenにも対応する。

Implicit Flow（`response_type=id_token`または`id_token token`）

Token Endpointを使わず、ID TokenやAccess Tokenを最初からAuthorization Endpointのレスポンスとして直接受け取る。トークンがブラウザに直接渡るため、リプレイ攻撃（傍受したリクエストを使い回すなりすまし攻撃）対策としてnonceパラメータが必須になる。もともとClient Secretを保管できないブラウザ完結型のJavaScriptアプリ（SPA）向けに定義されたフローで、Refresh Tokenには対応しない。

Hybrid Flow（`response_type=code id_token`など）

一部のトークンをAuthorization Endpointから即座に受け取りつつ、残りはCode経由でToken Endpointからも受け取る、2つの方式のいいとこ取りだ。「クライアント側ですぐにID Tokenを検証したい、かつToken Endpointへの安全なアクセスも欲しい」というケース（モバイルアプリ等）で使われる。

3つを並べてみると、違いは「トークンをどの経路（Authorization Endpoint経由かToken Endpoint経由か）で、どのタイミングで受け取るか」という1点に集約されることが分かった。安全性を優先するほどToken Endpoint経由の比率が増え、即時性を優先するほどAuthorization Endpoint経由の比率が増える、というトレードオフの構造になっている。

ID Tokenの中身

ID TokenはJWTなので、iss（発行者）・sub（ユーザーの一意識別子）・aud（想定される受け手）・exp（有効期限）・iat（発行時刻）が必須クレームとして定義されている。加えて、Implicit/Hybrid FlowではAuthorization Endpointから返るぶんにnonceが必須になる。さらにat_hash（Access Tokenのハッシュ）やc_hash（Authorization Codeのハッシュ）を含めることで、一緒に返ってきた他のトークンが改ざんされていないかをID Token側からも検証できるようになっている。

スコープとClaim

認証リクエストのscopeパラメータにopenidを含めることが、OpenID Connectとして扱われるための必須条件だ。これがないと単なるOAuth 2.0リクエストとして処理される。そのほかprofile（名前・写真等）、email、address、phoneといった標準スコープが用意されていて、必要なClaimの塊を単位でまとめてリクエストできる。より細かく「このClaimは必須」「これはあれば嬉しい程度」を個別に指定したい場合は、claimsパラメータでEssential/Voluntaryを指定する仕組みも用意されている。

今日の学び

OAuth 2.0とOpenID Connectは別物ではなく、後者は前者の上に「認証」を足すための薄い拡張レイヤーだった。両者を「同じもの」として曖昧に扱っていた部分がクリアになった
3つのフローの違いは、詰まるところ「トークンをどの経路でいつ受け取るか」のバリエーションで、安全性と即時性のトレードオフとして理解すると覚えやすい
ID Tokenは単なる「ログイン済みフラグ」ではなく、at_hashやc_hashのように他のトークンの改ざん検知まで担っている、検証可能な構造を持つドキュメントだった

コードを書かずに仕様書とじっくり向き合う一日だったが、CodeNoteが今Supabase Authに委ねている部分の裏側で何が起きているのかを言語化できたのは収穫だった。次に認証まわりを触る機会があれば、今日整理した用語をそのまま使って設計を検討したい。

本記事は Sonnet 5（claude-sonnet-5）が生成しました。