OpenID Connect

OpenID Connect（OIDC）とは、OAuth 2.0プロトコルの上に構築された認証レイヤーです。OAuth 2.0が「認可（誰が何にアクセスできるか）」を扱うプロトコルであるのに対し、OIDCは「認証（この人は誰か）」の機能を追加します。2014年にOpenID Foundationによって策定されました。

OIDCの最大の特徴は、IDトークンの発行です。IDトークンはJWT（JSON Web Token）形式で発行され、ユーザーの識別情報（クレーム）が含まれています。これにより、クライアントアプリケーションはユーザーが誰であるかを確実に確認できます。

「Googleでログイン」「Appleでサインイン」「Microsoftアカウントでログイン」といったソーシャルログイン機能の多くは、OIDCをベースに実装されています。SAMLがエンタープライズ環境のSSO向けに設計されたXMLベースのプロトコルであるのに対し、OIDCはJSONベースでRESTfulなアーキテクチャを採用しており、モバイルアプリやSPA（シングルページアプリケーション）など、モダンなアプリケーション開発に適しています。

シンプルさと拡張性を兼ね備えたOIDCは、現在最も広く採用されているID連携プロトコルの一つであり、コンシューマー向けサービスからエンタープライズまで幅広く利用されています。

IDトークンとJWT

IDトークンはOIDCの核心的な構成要素で、JWT（JSON Web Token）形式で発行されます。JWTはヘッダー、ペイロード、署名の3つの部分をBase64URLエンコードし、ドット（.）で連結した文字列です。

IDトークンのペイロードには以下のような標準クレーム（属性情報）が含まれます。

• iss（Issuer）：トークンを発行したOIDCプロバイダーの識別子
• sub（Subject）：ユーザーの一意な識別子
• aud（Audience）：トークンの受け取り対象となるクライアントID
• exp（Expiration）：トークンの有効期限
• iat（Issued At）：トークンの発行日時
• nonce：リプレイ攻撃防止のためのランダム値
• auth_time：ユーザーが認証された時刻

OIDCの認証フロー

• Authorization Code Flow：サーバーサイドアプリケーション向けの最もセキュアなフロー。認可コードを介してトークンを取得するため、トークンがブラウザに露出しない。PKCE（Proof Key for Code Exchange）と組み合わせることでさらに安全性が向上する。
• Implicit Flow：SPAなどのクライアントサイドアプリケーション向けに設計されたフロー。トークンが直接フラグメントで返されるため、セキュリティリスクがある。現在はAuthorization Code Flow + PKCEへの移行が推奨されている。
• Hybrid Flow：Authorization Code FlowとImplicit Flowを組み合わせたフロー。認可レスポンスで一部のトークンを即時受け取りつつ、認可コードでさらにトークンを取得できる。

UserInfoエンドポイント

UserInfoエンドポイントは、OIDCプロバイダーが提供するRESTful APIで、アクセストークンを使用してユーザーの追加属性情報を取得できます。IDトークンに含まれないプロフィール情報（氏名、メールアドレス、プロフィール画像など）を取得する際に使用されます。

Discovery（ディスカバリ）

OIDCプロバイダーは.well-known/openid-configurationエンドポイントでプロバイダーのメタデータをJSON形式で公開します。認可エンドポイント、トークンエンドポイント、UserInfoエンドポイント、サポートするスコープやクレーム、署名アルゴリズムなどの設定情報が含まれ、クライアントの自動設定を可能にします。

Dynamic Client Registration

動的クライアント登録により、クライアントアプリケーションはOIDCプロバイダーにプログラム的に登録できます。これにより、管理者の手動介入なしにクライアントの登録と設定を自動化できます。ただし、セキュリティ上のリスクもあるため、利用には慎重な検討が必要です。

SAMLとの比較

SAMLがXMLベースで複雑な構造を持つのに対し、OIDCはJSONベースでシンプルです。SAMLはエンタープライズ環境でのWebブラウザベースのSSOに強みがあり、OIDCはモバイルアプリやAPI連携を含むモダンなアーキテクチャに適しています。多くの組織では、レガシーシステムにはSAMLを、新規システムにはOIDCを採用するハイブリッドなアプローチを取っています。

• 01
  Authorization Code Flow + PKCEを使用する：Implicit Flowの使用を避け、Authorization Code FlowとPKCE（Proof Key for Code Exchange）を組み合わせて使用する。PKCEは認可コードの横取り攻撃を防止し、パブリッククライアント（モバイルアプリ、SPA）でも安全なトークン取得を実現する。
• 02
  IDトークンの検証を厳密に行う：署名の検証（JWKSエンドポイントから公開鍵を取得）、iss（発行者）、aud（対象者）、exp（有効期限）、nonce（リプレイ防止）のすべてを検証する。署名アルゴリズムはRS256以上を使用し、none アルゴリズムを許可しない。
• 03
  リダイレクトURIの厳密な検証：オープンリダイレクト脆弱性を防ぐため、リダイレクトURIは完全一致で検証する。ワイルドカードやパターンマッチングの使用を避け、登録済みのURIのみを許可する。localhostのリダイレクトは開発環境に限定する。
• 04
  stateパラメータとnonceパラメータを必ず使用する：stateパラメータはCSRF攻撃を防止し、nonceパラメータはIDトークンのリプレイ攻撃を防止する。どちらも暗号論的に安全な乱数生成器で生成し、セッションと紐付けて検証する。
• 05
  トークンの安全な保存と管理：アクセストークンやリフレッシュトークンをlocalStorageに保存しない（XSS攻撃で窃取されるリスク）。Webアプリケーションでは、HttpOnly・Secure・SameSite属性を設定したCookieに保存するか、BFF（Backend for Frontend）パターンを採用する。
• 06
  スコープの最小化とユーザー同意の適切な管理：アプリケーションが要求するスコープは業務上必要な最小限に制限する。openid以外のスコープ（profile、email、address、phone）は必要な場合のみ要求し、ユーザーに対して明確な同意画面を表示する。