OpenID Connect とフェデレーション認証の信頼モデル

OIDC が解く問題：OAuth は「認可」であって「認証」ではない

「Google でログイン」のようなソーシャルログインの裏で動くのが OpenID Connect（OIDC）です。ここでまず押さえるべきは、土台である OAuth 2.0 が**認可（authorization）**の枠組みであって、認証（authentication）の枠組みではない、という点です。OAuth が発行するアクセストークンは「このアプリは当該ユーザーの何々の API を呼んでよい」という権限の委譲証であり、「いま誰がログインしたか」を表すものではありません。両者の違いは認証と認可の違いの通りで、ここを混同すると設計を誤ります。

OAuth だけでログインを実装しようとすると、有名な落とし穴に落ちます。アクセストークンはリソースサーバーに提示するための文字列にすぎず、どのアプリ宛てに発行されたかが受け手に伝わりません。攻撃者が別アプリ向けに正規取得したアクセストークンを使い回し、/userinfo 的なエンドポイントに投げて得たユーザー ID で「ログイン成功」と判定してしまうと、なりすましが成立します（いわゆる confused deputy 問題）。OIDC はこれを、宛先（aud）を含み IdP が署名した ID トークンを1枚足すことで根本から塞ぎます。

主要な登場人物と用語の対応

OIDC では OAuth のロール名がそのまま使われますが、認証文脈の別名も併記されます。最初にこの対応を固定しておくと混乱しません。

ここで決定的に重要なのは、ID トークンの受け手は RP、アクセストークンの受け手はリソースサーバーだという宛先の違いです。RP が検証すべきは ID トークンであって、アクセストークンを「復号して中を見る」ものではありません（アクセストークンは IdP にとって不透明な文字列でよい）。この役割分担が、後述する aud 検証の根拠になります。

ID トークンの中身：署名付き JWT としての構造

ID トークンの実体は JWS（JSON Web Signature）形式の JWT です。ヘッダ.ペイロード.署名 の3つを base64url で連結した文字列で、ヘッダとペイロードは暗号化されておらず誰でもデコードして読めます。秘密は守られず、守られるのは**真正性（誰が発行し、改竄されていないか）**だけです。これはデジタル署名が機密性ではなく完全性と認証を担うのと同じ性質です。

# ID トークン（JWT）の3部構成
ヘッダ   : {"alg":"RS256","kid":"a1b2","typ":"JWT"}   # 署名アルゴリズムと鍵ID
ペイロード: {                                          # クレーム（主張）の集合
  "iss": "https://idp.example.com",   # 発行者。誰が署名したか
  "sub": "248289761001",              # ユーザーの一意かつ不変な識別子
  "aud": "rp-client-id-123",          # 宛先。このトークンを使ってよい RP
  "exp": 1718960000,                  # 有効期限（UNIX 秒）
  "iat": 1718956400,                  # 発行時刻
  "nonce": "n-0S6_WzA2Mj",            # リプレイ対策。認可要求の値と一致必須
  "auth_time": 1718956390             # 実際に本人確認した時刻
}
署名     : RS256( base64url(ヘッダ) + "." + base64url(ペイロード), IdPの秘密鍵 )

各クレームには明確な役割があります。iss は「どの IdP が署名したか」、sub は「その IdP の中で一意かつ不変なユーザー ID」です。ここで注意すべきは、sub はあくまで iss の名前空間内でのみ一意だという点で、アプリのユーザーキーは常に (iss, sub) の組で持つのが原則です。email を主キーに使うのは、IdP 側でメールが変更・再割り当てされうるため危険です。aud がこのトークンを使ってよい RP の識別子、exp が失効時刻、nonce がリプレイ対策の使い捨て値です。

鍵配布の自動化：ディスカバリと JWKS

ID トークンの署名を RP が検証するには、IdP の公開鍵が要ります。これを手作業で配ると鍵ローテーションのたびに破綻するため、OIDC は2段の自動発見を標準化しています。

第一段がディスカバリです。RP は https://<issuer>/.well-known/openid-configuration を GET し、そこに書かれた各エンドポイント（認可・トークン・UserInfo）と、署名鍵の置き場所である jwks_uri を得ます。第二段が **JWKS（JSON Web Key Set）**で、jwks_uri を GET すると現在有効な公開鍵の集合が返ります。

# 1) ディスカバリ：エンドポイントと鍵の場所を発見
GET https://idp.example.com/.well-known/openid-configuration
{
  "issuer": "https://idp.example.com",
  "authorization_endpoint": "https://idp.example.com/authorize",
  "token_endpoint": "https://idp.example.com/token",
  "userinfo_endpoint": "https://idp.example.com/userinfo",
  "jwks_uri": "https://idp.example.com/keys",          # ← 公開鍵の置き場
  "id_token_signing_alg_values_supported": ["RS256"]
}

# 2) JWKS：現在有効な公開鍵の集合（複数並ぶ）
GET https://idp.example.com/keys
{ "keys": [
  { "kty":"RSA", "kid":"a1b2", "use":"sig", "n":"...", "e":"AQAB" },
  { "kty":"RSA", "kid":"c3d4", "use":"sig", "n":"...", "e":"AQAB" }   # 新旧併存
]}

検証の実際は単純です。RP は受け取った ID トークンのヘッダの kid を読み、JWKS の中から同じ kid を持つ公開鍵を選び、その鍵で署名を検証します。鍵が複数並ぶのはローテーションを無停止で行うためで、IdP は「新鍵を JWKS に追加 → しばらく新旧併存 → 旧鍵で署名したトークンが全て失効してから旧鍵を削除」という手順を踏みます。RP 側は JWKS を短時間キャッシュしつつ、未知の kid が来たら再取得する実装が定石です。これはX.509 のチェーン検証が信頼の起点をルート CA に置くのと違い、信頼の起点が「issuer から HTTPS で取得した JWKS」に置かれている点が対照的です。

RP がやるべき検証：信頼境界はここに引かれる

OIDC のセキュリティは、ほぼ全面的に RP 側の ID トークン検証に懸かっています。IdP がどれだけ厳密でも、RP が検証を省けば信頼境界は崩れます。最低限、次の検証はすべて必須です。

とりわけ aud と nonce が、OAuth 単体では塞げなかった穴を埋める要です。aud 検証は「このトークンはこの RP のために発行された」ことを保証し、冒頭の confused deputy（別アプリ向けトークンの流用）を阻止します。nonce は認可要求時に RP が生成した使い捨て乱数で、IdP がそれを ID トークンにそのまま埋め戻すため、**RP は「自分が今回の要求で送った nonce と一致するか」**を確認することで、盗んだ古いトークンの再送（リプレイ）を弾けます。これは多要素認証が別要素で本人性を補強するのとは別軸の、トークンの鮮度と宛先を担保する仕組みです。

UserInfo エンドポイントと、ID トークンとの使い分け

ID トークンには認証の事実（誰が・いつ）を載せ、メールや氏名などのプロフィール属性は UserInfo エンドポイントから別途取得するのが OIDC の流儀です。RP は受け取ったアクセストークンを Authorization: Bearer で UserInfo に提示し、IdP がそのトークンに紐づくユーザーの属性を JSON で返します。

GET https://idp.example.com/userinfo
Authorization: Bearer <access_token>
->
{ "sub":"248289761001", "name":"Taro Yamada",
  "email":"taro@example.com", "email_verified": true }

両者を分ける理由は、ID トークンを軽量に保ち、要求スコープに応じて属性開示を可変にするためです。ただし UserInfo 応答の sub は、ID トークンの sub と必ず一致することを確認しなければなりません。一致確認を怠ると、別ユーザーのアクセストークンで引いたプロフィールを取り違える危険があります。属性の取得経路（ID トークン直載せか UserInfo か）は IdP 実装で異なるため、RP は両対応にしておくのが安全です。

フェデレーション設計：信頼を一点に集約する構図

最後に、なぜこの構造が「フェデレーション認証」と呼ばれるかを設計の視点で整理します。フェデレーションとは、複数の RP が共通の IdP に本人確認を委譲し、認証情報（ID トークン）を相互運用可能な形で受け渡す構図を指します。各 RP は自前で資格情報（パスワード）を保持せず、本人確認の責務を IdP に一点集約します。

この集約には明確な利益と代償があります。利益は、パスワード保管箇所が IdP の1点に減り、各 RP の攻撃面が縮小すること、そして利用者が一度のログインで複数 RP に入れるシングルサインオンが成立することです。代償は、IdP が単一障害点かつ単一の侵害点になることです。IdP の署名鍵が漏れれば、その IdP を信頼する全 RP のログインが偽造可能になります。だからこそ署名鍵のローテーション（JWKS）と HSM 等での鍵保護が、フェデレーション全体の安全性を左右します。

まとめると、OIDC は OAuth の認可基盤の上に「署名付き ID トークン＋鍵の自動配布＋RP 側の厳密検証」を薄く重ねることで、認証を標準化したプロトコルです。信頼境界は「RP が IdP の署名と iss/aud/exp/nonce を検証する」一点に集約され、そこを正しく実装することがフェデレーション全体の安全性を決めます。関連して、パスワード自体を排す方向のFIDO2 / WebAuthnと組み合わせると、IdP 側の本人確認をさらに堅牢にできます。