OpenID Connectとは？一言でいうと「OAuth 2.0に本人確認機能を追加した規格」
OpenID Connect（OIDC）は、OAuth 2.0の上に認証（本人確認）レイヤーを追加した標準規格です。2014年にOpenID Foundationによって策定されました。
OAuth 2.0が「このアプリにデータアクセスを許可する」という認可の仕組みであるのに対し、OpenID Connectは「このユーザーが誰であるか」を確認する認証を実現します。
身近な例でいえば、Webサービスで見かける「Googleでログイン」「LINEでログイン」ボタンの裏側で動いているのがOpenID Connectです。
なぜOAuth 2.0だけでは不十分なのか？
OAuth 2.0は「認可」のフレームワークであり、「認証」の仕組みは含まれていません。具体的には以下の問題があります。
| OAuth 2.0の限界 | OpenID Connectの解決策 |
|---|---|
| アクセストークンからユーザーが誰かわからない | IDトークンにユーザー情報を含めて返す |
| ユーザー情報の取得方法が標準化されていない | UserInfoエンドポイントを標準化 |
| 認証の方法・結果の表現がバラバラ | 認証イベントの情報をIDトークンに標準形式で格納 |
つまりOpenID Connectは、OAuth 2.0の「足りない部分」を補完するために生まれた規格です。
IDトークンとは？OpenID Connectの核心
OpenID Connectの最大の特徴はIDトークンの存在です。IDトークンはJWT（JSON Web Token）形式で発行され、以下の情報を含みます。
| クレーム（項目） | 意味 | 例 |
|---|---|---|
| iss | 発行者（IdPのURL） | https://accounts.google.com |
| sub | ユーザーの一意識別子 | 1234567890 |
| aud | このトークンの対象（クライアントID） | myapp.example.com |
| exp | 有効期限 | 1615984000（UNIXタイムスタンプ） |
| iat | 発行時刻 | 1615980400 |
| nonce | リプレイ攻撃防止用の値 | abc123xyz |
IDトークンはデジタル署名されているため、受け取ったアプリ側で改ざん検知が可能です。これにより、「この人は確かにGoogleで認証されたユーザーである」と安全に確認できます。
OpenID Connectの認証フロー
認可コードフロー（最も推奨）
OpenID ConnectはOAuth 2.0のフローをそのまま活用しつつ、レスポンスにIDトークンを追加します。
Step 1：ユーザーが「Googleでログイン」をクリック
Step 2：アプリがGoogleの認可エンドポイントにリダイレクト（scope に openid を含める）
Step 3：ユーザーがGoogleで認証・同意
Step 4：Googleが認可コードをアプリに返す
Step 5：アプリがトークンエンドポイントで認可コードを交換し、アクセストークン＋IDトークンを受け取る
Step 6：IDトークンを検証してユーザー情報を取得、ログイン完了
OAuth 2.0との違いは、Step 2でscope=openidを指定する点と、Step 5でIDトークンが返される点です。
その他のフロー
| フロー | 用途 | IDトークンの受け取り方 |
|---|---|---|
| インプリシットフロー | SPA（非推奨になりつつある） | リダイレクト時に直接返される |
| ハイブリッドフロー | フロント＋バックエンドの組み合わせ | 認可コードとIDトークンの両方が返される |
OAuth 2.0 vs OpenID Connect：完全比較
| 比較項目 | OAuth 2.0 | OpenID Connect |
|---|---|---|
| 目的 | 認可（リソースへのアクセス許可） | 認証（ユーザーの本人確認） |
| 発行トークン | アクセストークン | アクセストークン＋IDトークン |
| ユーザー情報 | 標準化なし | UserInfoエンドポイントで標準化 |
| 必須スコープ | なし | openid |
| 典型的な用途 | API連携、データアクセス委譲 | ソーシャルログイン、SSO |
| 関係性 | 基盤 | OAuth 2.0の拡張レイヤー |
Discovery（自動検出）とJWKS
OpenID Connectには、設定を自動取得する仕組みが標準化されています。
Discovery エンドポイント
https://IdPのURL/.well-known/openid-configuration にアクセスすると、認可エンドポイント、トークンエンドポイント、対応するスコープなどの情報がJSON形式で返されます。これにより、アプリ側での設定ミスを減らせます。
JWKS（JSON Web Key Set）
IDトークンの署名を検証するための公開鍵情報です。Discovery経由でJWKSエンドポイントのURLが取得でき、アプリはここから公開鍵を取得してIDトークンの署名を検証します。
よくある質問（FAQ）
Q. OpenID ConnectとSAMLの違いは？
どちらも認証プロトコルですが、SAMLはXMLベースでエンタープライズ向け、OIDCはJSONベースでモダンなWebアプリやモバイルアプリ向けです。新規開発ではOIDCが主流ですが、既存の企業システムではSAMLが依然として使われています。
Q. OpenID 2.0とOpenID Connectは同じものですか？
名前は似ていますが別物です。OpenID 2.0は独自の認証プロトコルで、OpenID ConnectはOAuth 2.0をベースに再設計されたまったく新しい規格です。現在、OpenID 2.0は非推奨です。
Q. 開発者としてOIDCを実装するには？
Google、Auth0、Keycloakなどの主要IdPはOIDCに対応しており、SDKやライブラリが充実しています。自前で一からOIDCを実装する必要はほぼありません。
まとめ：OpenID ConnectはモダンWeb認証の標準
OpenID Connectは、OAuth 2.0に認証機能を追加した規格で、IDトークンによる安全なユーザー識別を実現します。ソーシャルログインやSSOの基盤技術として、現代のWebサービスに欠かせない存在です。OAuth 2.0が「何を許可するか」、OpenID Connectが「誰であるか」を担当する——この役割分担を理解することが、認証・認可設計の第一歩です。
コメント