OpenID Connectとは？その仕組みと必要な知識とフローをまとめて解説

「ソーシャルログイン」や「Googleアカウントでサインイン」という機能を見たことがある方は多いと思います。その裏側で動いているのが OpenID Connect（OIDC） というプロトコルです。

本記事では、OpenID Connectがなぜ生まれたのか、OAuth 2.0との関係、IDトークンの構造、そして実際の認証フローまでを体系的に解説します。Web開発や認証設計に携わるエンジニアの方に特におすすめの内容です。

OpenID Connectとは何か

OpenID Connect（OIDC）は、OAuth 2.0をベースにした認証のための拡張仕様です。OAuth 2.0はアクセス権の委譲（認可）を行うプロトコルですが、「このユーザーが誰であるか」を確認する機能（認証）は持っていません。OIDCはその不足を補うために策定されました。

OpenID Foundationが策定し、OpenID Connect Core 1.0 として仕様が公開されています。2024年にはISO/IEC 26131:2024として国際標準規格にも認定されており、Google・Microsoft・GitHubなど主要なIDプロバイダーが採用しています。

OAuth 2.0とOpenID Connectの違い

OAuth 2.0は「アクセストークン」を発行してAPIへのアクセスを制御するプロトコルです。しかし、アクセストークン自体にはユーザー情報が含まれておらず、「誰がログインしているか」を特定することができません。

OpenID ConnectはOAuth 2.0の上に認証レイヤーを追加することで、この課題を解決します。具体的には「IDトークン」という新しいトークンを導入し、そこにユーザーの身元情報（クレーム）をJWT形式で含める仕組みを定義しています。

OpenID Connectに登場する主なロール

OpenID Connectの通信には、以下の3つの主要な登場人物がいます。それぞれの役割を把握することが、フローを理解する上での第一歩です。

• エンドユーザー（End-User）：ログインを行う人間のユーザーです。ブラウザやアプリを通じて操作します。
• RP（Relying Party）：ユーザーのログインを必要とするアプリケーション側（例：あなたが開発するWebサービス）。OPから認証情報を受け取り、ユーザーのセッションを管理します。
• OP（OpenID Provider）：ユーザーの認証を行い、IDトークンを発行する側です（例：Google、GitHub、Microsoft Entra IDなど）。IDプロバイダー（IdP）とも呼ばれます。

RPはOPに対してユーザーの認証を依頼し、認証が成功するとOPからIDトークンおよびアクセストークンを受け取ります。RPがOPを特定し、各エンドポイント情報を取得する仕組みを「Discovery」と呼びます。

OPが提供する主要なエンドポイント

OPはRPが利用するための複数のエンドポイントを提供します。代表的なものは以下の3つです。

また、OPは /.well-known/openid-configuration という Discoveryエンドポイント を公開しており、RPはここへアクセスするだけで上記エンドポイントのURLや署名鍵（JWKs URI）などを自動取得できます。

IDトークンの構造と主要クレーム

IDトークンは JWT（JSON Web Token） 形式で表現されます。JWTは Header.Payload.Signature の3パートを .（ドット）で区切った文字列です。各パートはBase64URLエンコードされています。

• Header：署名アルゴリズム（alg）やトークン種別（typ）を示します。例：{"alg": "RS256", "typ": "JWT"}
• Payload：ユーザー情報やトークンのメタデータを「クレーム（Claims）」という形で格納します。
• Signature：HeaderとPayloadをOPの秘密鍵で署名したものです。RPは対応する公開鍵で検証することで改ざんを検知できます。

OpenID Connect Core 1.0が定める必須クレームは以下の通りです。

また、スコープに profile や email を追加することで、name・email・picture などのユーザー属性クレームを追加取得できます。

{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "my-app-client-id",
  "exp": 1712345678,
  "iat": 1712342078,
  "email": "user@example.com",
  "email_verified": true,
  "name": "Taro Yamada",
  "nonce": "abc123xyz"
}

Authorization Code Flow with PKCE の詳細

現在最も広く推奨されている認証フローが Authorization Code Flow with PKCE（認可コードフロー + PKCE）です。Webアプリ・モバイルアプリ・SPA（シングルページアプリケーション）のいずれにも適用できます。

1. ログインリクエスト：ユーザーがRPのログインボタンを押すと、RPが処理を開始します。
2. PKCE パラメータ生成：RPはランダムな文字列 code_verifier を生成し、そのSHA-256ハッシュ値を code_challenge として準備します。
3. 認証エンドポイントへリダイレクト：RPはユーザーをOPの認証エンドポイントへリダイレクトします。この際、scope=openid・response_type=code・client_id・redirect_uri・state・code_challenge などのパラメータを付与します。
4. ログイン画面の表示：OPがユーザーにログイン画面を表示します。
5. ユーザー認証：ユーザーがID/パスワードを入力し、OPが認証を行います。
6. 認可コードの返却：認証成功後、OPはRPの redirect_uri へ認可コードをリダイレクトで返します。
7. トークンリクエスト：RPはトークンエンドポイントへ、認可コードと code_verifier を送信します。
8. IDトークン・アクセストークンの返却：OPは code_verifier と code_challenge の一致を検証し、問題なければIDトークンとアクセストークンを返却します。
9. UserInfoの取得（任意）：追加のユーザー情報が必要な場合、RPはアクセストークンを使ってUserInfoエンドポイントを呼び出します。
10. ログイン成功：RPはIDトークンを検証し、ユーザーのセッションを開始します。

PKCEとはなぜ必要か

PKCE（Proof Key for Code Exchange / ピクシー）は、認可コード横取り攻撃（Authorization Code Interception Attack）を防止するための拡張機能です。

モバイルアプリやSPAではクライアントシークレットを安全に保管できません。そのような環境で認可コードが第三者に傍受された場合、従来のフローではそのままトークンを取得されてしまいます。PKCEでは事前に生成した code_verifier を使った検証をOPに行わせるため、認可コードだけを持っていても不正にトークンを取得できなくなります。

# code_verifier: ランダムな文字列（43〜128文字）
code_verifier=$(openssl rand -base64 32 | tr -d '=+/' | head -c 43)

# code_challenge: code_verifier の SHA256 ハッシュを Base64URL エンコード
code_challenge=$(echo -n "$code_verifier" | openssl dgst -sha256 -binary | base64 | tr '+/' '-_' | tr -d '=')

echo "code_verifier: $code_verifier"
echo "code_challenge: $code_challenge"

認証リクエストの主要パラメータ

RPがOPの認証エンドポイントにリクエストを送る際の主なパラメータを確認しておきましょう。

# 認可リクエストの例（クエリパラメータ）

https://accounts.google.com/o/oauth2/v2/auth
accounts.google.com
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https%3A//your-app.example.com/callback
  &scope=openid%20email%20profile
  &state=RANDOM_STATE_VALUE
  &nonce=RANDOM_NONCE_VALUE
  &code_challenge=CODE_CHALLENGE_VALUE
  &code_challenge_method=S256

その他の認証フロー（Implicit Flow・Hybrid Flow）

OpenID Connect Core 1.0 では、Authorization Code Flow 以外にも以下のフローが定義されています。ただし、現在のセキュリティベストプラクティスではAuthorization Code Flow with PKCE の使用が強く推奨されており、Implicit Flow は非推奨となっています。

• Implicit Flow（response_type=id_token token）：認可コードを介さず、リダイレクトURLのフラグメント部分にIDトークンを直接返すフローです。かつてSPAで使われていましたが、トークンがURLに露出するリスクがあり現在は非推奨です。
• Hybrid Flow（response_type=code id_token など）：認可コードとIDトークンを同時に返すフローです。特定のユースケース（ネイティブアプリ等）で利用されます。

OpenID Connectの主な活用シーン

OpenID Connectは以下のような場面で広く活用されています。

• ソーシャルログイン：「Googleでログイン」「GitHubでサインイン」など、外部IDプロバイダーのアカウントで自社サービスにログインする機能。ユーザーは新たなID/パスワードを覚える必要がなくなります。
• シングルサインオン（SSO）：一度認証すれば、複数のサービスを再認証なしで利用できます。企業内の複数システムへのアクセスや、マイクロサービス間の認証に活用されます。
• モバイルアプリ・SPAの認証：PKCE対応のAuthorization Code Flowにより、クライアントシークレットを持てない環境でも安全な認証が実現できます。
• B2B SaaSのアイデンティティ連携：企業ごとのAD（Active Directory）やSAMLプロバイダーと連携し、従業員が自社アカウントで外部SaaSにログインできます。

まとめ

OpenID Connectは、OAuth 2.0の認可機能にIDトークンという認証レイヤーを追加したプロトコルです。本記事で解説した内容を以下に整理します。

• OIDCはOAuth 2.0の拡張であり、「認証」を担うプロトコルである
• IDトークン（JWT）にはユーザー情報がクレームとして含まれ、OPの秘密鍵で署名される
• 主要なフローはAuthorization Code Flow with PKCEであり、認可コード横取り攻撃を防止できる
• RPとOPの間では認証エンドポイント・トークンエンドポイント・UserInfoエンドポイントを使って通信する
• Discoveryエンドポイントにより、RPはOPの設定情報を自動取得できる

認証設計において「ソーシャルログインを実装したい」「SSOを構築したい」という場面では、OIDCの仕様を正しく理解した上で実装することがセキュリティ上も重要です。ぜひ本記事をリファレンスとして活用してください。

参考リソース

• OpenID Foundation – OpenID Connect Core 1.0 仕様書
• OpenID Foundation – How OpenID Connect Works
• Auth0 Docs – OpenID Connect Protocol
• Auth0 Docs – IDトークンの構造
• Microsoft Learn – Microsoft ID プラットフォームでの OpenID Connect
• Qiita – IDトークンが分かれば OpenID Connect が分かる
• Zenn – OAuth 2.0 認可コードフロー+PKCE をシーケンス図で理解する
• とほほのWWW入門 – とほほのOpenID Connect入門