OpenID Connect（OIDC）

OpenID Connect は、OAuth 2.0 の上に構築された軽量なアイデンティティ層です。OAuth が答えるのはこのアプリで何ができるかであり、OIDC が答えるのはユーザーが誰であるかです。

• クライアントがユーザーを認証し、検証済みのアイデンティティクレームを受け取る方法を標準化します。
• 認証を示す暗号学的に署名されたアサーションとして、ID トークンを導入します。

OIDC が登場する前は、開発者が OAuth アクセストークンをログインに誤用しており、混乱した代理人やなりすましのバグにつながっていました。

OIDC を特徴づける成果物は、認証イベントを説明する署名付き JWT である ID トークンです。

• 誰が、いつログインしたかに関するクレームを含みます。
• クライアントが利用するためのものであり、リソースサーバーが利用するものではありません。

ID トークンをアクセス資格情報として API に送信しないでください。また、署名とクレームを検証せずに受け入れてはいけません。

ID トークンを検証するには、署名だけでなく特定のクレームも確認する必要があります。

• iss（発行者）は、想定している IdP と一致しなければなりません。
• aud（対象者）には、client_id が含まれていなければなりません。
• exp / iat により、トークンが有効期限内で最近発行されたことを確認します。
• sub は、安定した一意のユーザー識別子です。
• nonce は、クライアントが送信した値と一致しなければなりません。

OIDC は Authorization Code フローを再利用しますが、openid スコープと nonce を追加します。

• クライアントは openid スコープ（任意で profile、email も）を要求します。
• トークンエンドポイントは、アクセストークンとともに ID トークンを返します。
• nonce は ID トークンを元のリクエストに結び付け、リプレイを防ぎます。

OIDC プロバイダーは、well-known 設定ドキュメントから検出できる JWKS エンドポイントで署名鍵を公開します。

• jwks_uri から鍵を取得し、トークンの kid ヘッダーと照合してください。
• 一覧に示された非対称アルゴリズム（RS256、ES256）で検証してください。

none アルゴリズムは拒否し、トークンだけから提供されたアルゴリズム値を決して信頼しないでください。

nonce は、リダイレクトにおける state に相当するものです。レスポンスをリクエストに結び付ける一度限りの値です。

• クライアントはランダムな nonce を生成し、セッションに保存します。
• IdP は ID トークン内にその値を返します。
• 受信時に、クライアントは nonce が一致し、以前に使用されていないことを検証します。

これにより、トークンのリプレイや、別のセッション向けに発行されたトークンの注入を防げます。

ID トークンに含まれる情報以外のプロフィールデータについては、OIDC が UserInfo エンドポイントを定義しています。

• クライアントは アクセストークン（ID トークンではありません）を使って呼び出します。
• 認証された subject の名前、メールアドレス、画像などのクレームを返します。

クレームのすり替えを防ぐため、返された sub と ID トークンの sub が常に一致することを確認してください。

OIDC はディスカバリーを標準化しており、クライアントはエンドポイントやサポートされる機能を自動設定できます。

• /.well-known/openid-configuration ドキュメントには、エンドポイント、サポートされるスコープ、アルゴリズムが記載されています。
• 発行者をピン留めするか検証し、攻撃者が制御するホストからのディスカバリーに盲目的に従わないでください。

ディスカバリーによって統合は簡単になりますが、発行者は検証すべき信頼の起点であることに変わりはありません。

フェデレーションされたアプリ間のセッション終了は、OIDC のログアウト仕様で処理します。

• フロントチャネルログアウトでは、ブラウザーのリダイレクトや iframe を使って各 relying party のセッションを消去します。
• バックチャネルログアウトでは、サーバー間でログアウトトークンを送信します。より信頼性が高い一方、エンドポイントが必要です。

ログアウトを連携しなければ、ユーザーは 1 つのアプリからサインアウトした後も、他のアプリにはログインしたままになる可能性があり、現実的なセッション管理上のリスクになります。

アイデンティティ関連のバグは、検証手順を省略することで発生することがよくあります。

• aud を確認せずにトークンを受け入れること（別のクライアント向けのトークン）。
• iss を無視することで、IdP のなりすましが可能になること。
• 署名を検証しないこと、または alg: none を受け入れること。
• ID トークンとアクセストークンを混同すること。
• nonce の確認を欠落させることで、リプレイが可能になること。

目的がログインであれば、OAuth 単体ではなく OIDC を使用してください。

• OAuth アクセストークンはクライアントから見て不透明であり、アイデンティティを何も証明しません。
• アクセストークンは別のユーザーやアプリに対して有効な場合があり、ログインに使用すると、なりすましにつながる可能性があります。
• OIDC の ID トークンは、対象者に明示的に紐付けられたアイデンティティアサーションです。

この区別により、古典的な confused-deputy 認証上の欠陥を防げます。

ID トークンを利用する Relying Party にとって、最も重要な検証手順を選択してください。

重要なポイント:

• OIDC は OAuth 2.0 にアイデンティティ層を追加します。ID トークンは、認証を証明する署名付き JWT です。
• iss、aud、exp、署名（JWKS 経由）、nonceを必ず検証してください。
• ID トークンはクライアント用、アクセストークンは API 用です。両者の役割を決して入れ替えないでください。
• リプレイ対策には nonce を、CSRF 対策には state を使用してください。
• ユーザーを認証する必要がある場合は、生の OAuth ではなく OIDC を使用してください。