OpenID Connect (OIDC) は、OAuth 2.0 プロトコルの上に構築された認証レイヤーです。 OAuth 2.0 が「認可」(リソースへのアクセス権の委譲)を扱うのに対し、 OIDC は「認証」(ユーザーが誰であるかの確認)を標準化された方法で実現します。
OIDC は 2014 年に OpenID Foundation によって策定され、 Google、Microsoft、Auth0 など多くのプロバイダーが採用しています。
OAuth 2.0 のアクセストークンは「このトークンの持ち主は、特定のリソースにアクセスする権限がある」 ということしか示しません。以下の重要な情報が欠けています。
- 誰がログインしたのか - アクセストークンにはユーザーの識別情報が含まれる保証がない
- いつ認証されたのか - トークンは過去の認証セッションから発行された可能性がある
- どのように認証されたのか - パスワード認証なのか、多要素認証なのかわからない
- トークンの対象者 - アクセストークンは特定のクライアント向けとは限らない
OAuth 2.0 のアクセストークンを認証に流用すると、 トークン置換攻撃やトークン横取りなど、深刻なセキュリティ問題が発生します。
1. IDトークン (ID Token)
JWT 形式のトークンで、ユーザーの認証情報を含みます。 誰が (sub)、いつ (iat/auth_time)、どのクライアント向けに (aud) 認証されたかを暗号的に証明します。
2. UserInfoエンドポイント
アクセストークンを使ってユーザーのプロフィール情報 (名前、メールアドレスなど)を取得できる標準化されたエンドポイントです。
3. ディスカバリドキュメント
.well-known/openid-configuration により、 プロバイダーのエンドポイントや対応機能を自動的に取得できます。 手動設定が不要になり、設定ミスを防ぎます。
4. 標準化されたスコープ
openid, profile, email, address, phone といった標準スコープが定義されており、 プロバイダー間で一貫したユーザー情報の取得が可能です。
| 項目 | OAuth 2.0 | OIDC |
|---|---|---|
| 目的 | 認可(アクセス委譲) | 認証 + 認可 |
| 発行トークン | アクセストークン | IDトークン + アクセストークン |
| ユーザー情報 | 標準なし | UserInfoエンドポイント |
| プロバイダー設定 | 手動 | ディスカバリで自動 |
| トークン形式 | 規定なし | IDトークンはJWT必須 |
OIDCを深く理解する
次のステップ
まずは IDトークン から学び始めましょう。OIDCの中核となるトークンの仕組みを理解することが、 全体を理解する鍵です。