OpenID Connect（OIDC）とは、OAuth 2.0を基盤としたアイデンティティレイヤーであり、アプリケーションがユーザーを認証し、そのプロファイル情報を取得できるようにする仕組みです。OAuth 2.0が認可（ユーザーがアクセスできる対象）を扱うのに対し、OIDCには標準化されたIDトークンを用いた認証（ユーザーが誰であるかの確認）の仕組みが追加されています。

例：Spotifyにサインインする際に「Googleで続行」をクリックすると、OIDCはGoogleを通じてユーザーの本人確認を行います。Spotifyはユーザーの氏名やEメールアドレスなどのプロファイル情報を受け取りますが、Googleのパスワードが共有されることはありません。Googleは、ユーザーIDやプロファイル情報などのアイデンティティクレームを含むIDトークンを発行します。一部のクレーム（Eメールの確認など）には、検証済みであることが明示的に示されます。

OIDCは、現在のWebアプリやモバイルアプリの認証方式として広く採用されています。2014年にOpenID Foundationによって公開されたOIDCは、OAuth 2.0の認可機能とアイデンティティ検証を組み合わせたものです。主要なアイデンティティプロバイダーがOIDCをサポートしているため、シングルサインオン（SSO）、ソーシャルログイン、消費者アプリケーションで広く利用されています。

OIDCが登場する前、開発者は主に次の3つの課題を抱えていました。

1. 標準化されたアイデンティティレイヤーの欠如

   OAuth 2.0は認可を提供しますが、標準化された相互運用可能な認証方式は定義していません。そのため、開発者は独自のソリューションを構築する必要があり、相互運用性の問題が生じていました。

2. 代替手段の複雑さ

   SAML 2.0はエンタープライズ向け認証をサポートしていますが、XMLベースの複雑な仕様を採用しており、証明書の管理が必要になるうえ、モバイルデバイスとの相性もあまりよくありません。

3. 認証情報の漏えいリスク

   以前は、アプリケーションがユーザーの認証情報を保存したり、パスワードの共有を必要としたりすることが多く、それがセキュリティリスクの増大やユーザーエクスペリエンスの低下につながっていました。

OIDCはこうした課題に対処します。アプリケーションは、アイデンティティクレームが含まれた、暗号学的に署名されたIDトークンを受け取ります。そのため、認証情報を保存する必要がなくなり、さまざまなプラットフォームで一貫した認証を実現できます。ただし、OIDCが担うのはユーザー認証までです。アプリケーション固有のユーザーデータ、ロール、権限は管理しません。

OIDCでは、OAuth 2.0の役割を基盤としながら、アイデンティティに関する独自の用語が定義されています。

• エンドユーザー：本人確認の対象となる人
• Relying Party（RP）：ユーザー認証を要求するアプリケーション
• OpenID Provider（OP）：ユーザーを認証し、IDトークンを発行するアイデンティティプロバイダー。OIDCにおいて、OPはOAuth 2.0の認可サーバーとして機能する

IDトークンのクレーム

IDトークンは、アイデンティティクレームを含むJSON Web Token（JWT）です。使用する前に必ず検証する必要があります。

• sub：発行者内でユーザーを一意に識別する、変更されない識別子
• iss：トークンの発行者（OpenID ProviderのURL）
  aud：トークンの対象となるアプリケーション（クライアントID）
• exp：有効期限（Unixタイムスタンプ）
• iat：発行日時（Unixタイムスタンプ）
• auth_time：認証が行われた日時
• nonce：リプレイ攻撃を防ぐための値（リクエストで送信された場合は必須）

OIDCでよく使用されるスコープ

スコープは、要求されたユーザー情報を定義します。

• openid：必須。OIDCを有効にする
• profile：氏名、写真、基本的なプロファイル情報
• email：Eメールアドレスとその検証状態
• address：住所情報
• phone：電話番号とその検証状態

OIDCはOAuth 2.0を拡張したプロトコルであるため、そのフローはOAuthのAuthorization Code Flowと似ていますが、OIDC独自の要素が追加されています。

OIDCの認証フロー

1. 認証リクエスト：RPは、クライアントID、リダイレクトURI、response_type=code、スコープ（openidなど）を指定して、ユーザーをOPにリダイレクトします。
2. ユーザー認証と同意：OPは、パスワード、MFA、または生体認証を使用してユーザーを認証します。その後、要求されている情報を示す同意画面が表示されます。
3. 認可レスポンス：OPは、認可コードとstateパラメーターを付与してユーザーをRPにリダイレクトします。
   トークンリクエスト：RPは認可コードを使用して、3種類のトークン（IDトークン、アクセストークン、必要に応じてリフレッシュトークン）を取得します。機密クライアントの場合、この処理はサーバー間で行われます。パブリッククライアントの場合はPKCEを使用します。
4. トークンの検証：RPは、プロバイダーの公開鍵（JWKS）を使用して、IDトークンの署名、有効期限、発行者（issuer）、対象者（audience）、nonceを検証します。IDトークンはクライアントアプリケーション専用であり、APIに送信してはいけません。APIでは、代わりにアクセストークンを検証する必要があります。
5. ユーザープロファイルへのアクセス：必要に応じて、RPはアクセストークンを使用してUserInfoエンドポイントを呼び出し、追加のプロファイルクレームを取得します。

PKCE（Proof Key for Code Exchange）

PKCEは、認可コードの横取り攻撃を防ぐための仕組みです。モバイルアプリやSPAなどのパブリッククライアントは、クライアントシークレットをセキュアに保管できないため、PKCEを使用します。一方、機密クライアントは通常、クライアントシークレットを用いて認証を行います。多層防御の観点から、近年では、機密クライアントでもPKCEを併用する構成が一般的になっています。

どのフローを使用するかは、以下のように判断します。

フロー	ユースケース	セキュリティ	ステータス
Authorization Code Flow with PKCE	すべてのモダンなアプリケーション（Web、モバイル、SPA）	最高	すべてのクライアントに推奨
Implicit Flow	無効	低	非推奨（RFC 8252）
Hybrid Flow	複雑なエンタープライズ環境	中程度	レガシー用途のみ

• Authorization Code Flow with PKCEは、推奨されるベストプラクティスであり、OAuth 2.1では必須になると見込まれている
• Implicit Flowは、セキュリティ上の脆弱性があるため非推奨となっている
• Hybrid Flowは主にレガシーシステムや特殊なエンタープライズ環境で使用されており、ほとんどのモダンなアプリケーションでは一般的に必要ない

IDトークンの検証

IDトークンは、署名、有効期限、発行者（issuer）、対象者（audience）、nonceを検証する必要があります。

検証手順：

• JWKSの鍵を使用して署名を検証する
• 発行者（issuer）がプロバイダーと一致することを確認する
• 対象者（audience）がクライアントIDと一致することを確認する
• トークンの有効期限が切れていないことを確認する
• nonceがリクエストの値と一致することを検証する

ベストプラクティス：検証機能を備えた実績のあるOIDCライブラリを使用します。

nonceの取り扱い

nonceはリプレイ攻撃を防ぎます。nonceがない場合、攻撃者は有効なIDトークンを再利用できる可能性があります。予測可能なnonceや再利用されたnonce、または検証されていないnonceは安全ではありません。

ベストプラクティス：暗号学的に安全なランダムnonceを生成し、5～10分の有効期限（TTL）を設定してサーバー側に保存し、値が完全に一致することを検証します。

トークンの保存

IDトークンには機密情報が含まれるため、クロスサイトスクリプティング（XSS）の脆弱性を考慮すると、localStorageやsessionStorageを使用して保存してはいけません。

ベストプラクティス：SPAではインメモリストレージを使用し、BFF（Backend for Frontend）パターンを採用する場合はセキュアなHTTP Only Cookieを使用します。サーバー側で暗号化されたセッションは、さらに安全です。

スコープの要求

アプリに必要なスコープのみを要求します。不要なプロファイルデータの取得は避けてください。

UserInfoエンドポイントの利用

UserInfoエンドポイントは、必要なクレームがIDトークンに含まれていない場合にのみ呼び出します。このエンドポイントを利用するにはアクセストークンが必要であり、多くの場合レート制限が設けられています。アクセストークンは必ず検証し、必要に応じてレスポンスをキャッシュしてください。

OIDCは、消費者向けアプリケーション、モバイルアプリ、モダンなWeb認証に特に適しています。ソーシャルログインやSSO、ユーザーが既存のアカウントを使用して認証するシナリオでは、OIDCを選択するとよいでしょう。

SAML 2.0は依然としてレガシーなエンタープライズシステムや政府機関のシステムで広く利用されていますが、多くの組織で従業員向けの新しいアプリケーションにOIDCを採用するケースが増えています。多くの組織では両方を併用しており、モダンなアプリにはOIDCを、エンタープライズフェデレーションにはSAMLを利用しています。

• JWKSの鍵を使用してIDトークンを完全に検証すること。署名、exp、iss、aud、nonceを確認すること（IDトークンをAPIに送信してはならない）
• 本番環境における通信はすべてHTTPSを使用すること。RFC 6749では、開発用途に限ってlocalhostの使用が認められている
• すべてのクライアントでPKCEを実装すること（OAuth 2.1では必須になると見込まれている）
• HTTP Only Cookieまたはサーバー側セッションを使用してトークンをセキュアに保存すること
• リダイレクトURIを明示的に検証すること。ワイルドカードを使用してはならない
• CSRF攻撃を防ぐためにstateパラメーターを実装すること
• 有効期間の短いトークンを使用し（15～60 分）、リフレッシュトークンのローテーションを有効にすること
• ユーザーの同意を尊重し、要求するプロファイルデータを最小限に抑えること

項目	OIDC	OAuth 2.0	SAML 2.0
目的	認証	認可	認証とSSO
基盤	OAuth 2.0	IETFのOAuth仕様	XMLベースのSAML標準
トークン形式	JWT	ベアラートークン（形式の規定なし）	XML
アイデンティティクレーム	標準化されている	定義されていない	属性ステートメント
モバイル対応	非常に優れている	非常に優れている	不十分
ユースケース	ユーザー認証、ソーシャルログイン	APIアクセス	Enterprise SSO
複雑度	低	低	高
ターゲット オーディエンス	モダンなアプリ	API	エンタープライズフェデレーション

OIDCとOAuth 2.0は相互に補完し合う関係にあります。OIDCは「このユーザーは誰か？」という問いに答える一方で、OAuth 2.0は「このユーザーは何にアクセスできるか？」という問いに答えます。SAMLはエンタープライズSSOで広く利用されています。一方、OIDCはモダンなアプリやモバイル環境で好まれています。

OAuth 2.0とOpenID Connectの違いは何ですか？

OAuth 2.0は認可のための仕組みです。OIDCはその上に認証機能を追加したものです。OAuthは「このアプリは何にアクセスできるのか？」という問いに答えます。一方、OIDCは「このユーザーは誰か？」という問いに答えます。

IDトークンとは何ですか？なぜ重要なのですか？

IDトークンは、プロバイダーが提供するアイデンティティクレームを含む署名付きJWTです。これは認証が行われたことを証明するものです。アクセストークンとは異なり、IDトークンはクライアントがユーザーの本人確認を行うために使用されます。署名が含まれているため、プロバイダーに問い合わせることなく検証できます。一般的なクレームには、ユーザーID（sub）、Eメールアドレス、認証時刻などがあります。IDトークンは必ず検証してください。

OAuth 2.0を使用せずにOIDCを利用できますか？

いいえ。OIDCはOAuth 2.0に基づいて構築されています。すべてのOIDCフローは、OAuth 2.0フローにopenidスコープとIDトークンを追加したものです。OIDCはOAuth 2.0の拡張であり、置き換えるものではありません。

OIDCはSAMLよりも安全ですか？

どちらも正しく実装されていれば安全です。OIDCでは比較的シンプルなJWTの検証を使用します。一方、SAMLではXML署名を使用するため、仕組みがより複雑です。ほとんどの脆弱性はプロトコル自体ではなく、実装上のミスによって発生します。OIDCはトークン形式がシンプルであるため、実装上のリスク低減に役立ちます。

UserInfoエンドポイントとは何ですか？

UserInfoエンドポイントは、追加のユーザープロファイルクレームを返します。このエンドポイントを利用するには、有効なアクセストークンが必要です。IDトークンは使用できません。必要なクレームがIDトークンに含まれていない場合にのみ利用してください。また、このエンドポイントにはレート制限が設けられていることが多いため、パフォーマンス向上のためにキャッシュを実装してください。

信頼できるプロバイダーが発行したIDトークンも検証する必要がありますか？

はい。署名、発行者（issuer）、対象者（audience）、有効期限、nonceを必ず検証してください。検証を行うことで、そのトークンが真正かつ有効であり、自身のアプリケーション向けに発行されたものであることを確認できます。信頼できるプロバイダーが発行したトークンであっても、改ざんやリプレイ攻撃を防ぐために検証する必要があります。

OIDCはHTTPSなしでも動作しますか？

いいえ。本番環境ではHTTPSが必須です。HTTP経由で送信されたトークンは、攻撃者によって傍受される可能性があります。localhostの例外が認められるのは、開発用途に限られます。

OIDCライブラリの使用

実績のあるライブラリは、トークンの検証、JWKSの鍵の管理、プロトコルの詳細な処理に対応しています。ライブラリを利用することで実装ミスの削減が期待できますが、そのためにはOIDCの概念を理解しておく必要があります。

代表的なオープンソースライブラリには次のようなものがあります。

• Node.js：openid-client
• Python：authlib
• Python：pyoidc
• Java：Spring Security OAuth

アイデンティティプラットフォームの使用

アイデンティティプラットフォームは、OIDCやOAuth 2.0の実装に加え、組み込みのセキュリティ機能、ソーシャルログイン、プロトコル変換機能を提供します。また、アップデートやコンプライアンス、スケーリングにも対応できるため、開発者はアプリケーションロジックに集中できます。

Auth0はOIDCとOAuth 2.0の実装を効率化し、認証やアイデンティティ管理を安全に実現しながら、開発者がアプリケーション開発に専念できるよう支援します。

アイデンティティとアクセス管理に関しては、「IAM入門」シリーズをご覧ください。

詳細を見る

これらの資料は一般的な情報提供のみを目的としています。本資料の利用者は、自身の責任において、自身の専門アドバイザーからセキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本資料に記載された情報のみに依存すべきではありません。