IT 技書の森

OpenID Connect

OAuth 2.0 の上に構築された認証レイヤーで、ユーザーの身元情報を ID トークンとして提供する

認証ネットワーク

OpenID Connect とは

OpenID Connect (OIDC) は、OAuth 2.0 の上に構築された認証レイヤーである。OAuth 2.0 が「認可」(何にアクセスできるか) を扱うのに対し、OIDC は「認証」(誰であるか) を扱う。認証成功時に ID トークン (JWT) を発行し、ユーザーの身元情報をクライアントに提供する。2014 年に OpenID Foundation が策定した。

OAuth 2.0 との違い

観点 OAuth 2.0 OpenID Connect
目的 認可 (リソースへのアクセス許可) 認証 (ユーザーの身元確認)
トークン アクセストークン ID トークン + アクセストークン
ユーザー情報 標準化されていない UserInfo エンドポイントで標準化
スコープ read, write など任意 openid, profile, email

OAuth 2.0 だけでは「このアクセストークンは誰のものか」が分からない。OIDC の ID トークンにユーザー情報が含まれる。

ID トークン (JWT)

{
  "iss": "https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_xxxxx",
  "sub": "user-123",
  "aud": "client-id",
  "exp": 1711900800,
  "iat": 1711897200,
  "email": "user@example.com",
  "name": "Alice",
  "email_verified": true
}
クレーム 説明
iss 発行者 (IdP の URL)
sub ユーザーの一意識別子
aud 対象のクライアント ID
exp 有効期限
email メールアドレス

認証フロー (認可コード + PKCE)

1. クライアントが認可リクエスト (scope: openid profile email)
2. ユーザーが IdP でログイン
3. IdP が認可コードを返す
4. クライアントが認可コードをトークンエンドポイントに送信
5. IdP が ID トークン + アクセストークンを返す
6. クライアントが ID トークンを検証 (署名、exp、aud)
7. UserInfo エンドポイントで追加情報を取得 (オプション)

Cognito での OIDC

Cognito User Pool は OIDC プロバイダーとして機能する。

// Cognito の OIDC エンドポイント
// 発見: https://<domain>/.well-known/openid-configuration
// 認可: https://<domain>/oauth2/authorize
// トークン: https://<domain>/oauth2/token
// UserInfo: https://<domain>/oauth2/userInfo
// JWKS: https://<domain>/.well-known/jwks.json

OIDC Discovery

.well-known/openid-configuration エンドポイントで、IdP の設定情報 (認可エンドポイント、トークンエンドポイント、JWKS URI) を自動取得できる。クライアントは IdP の URL だけ知っていれば、残りの設定を自動的に取得する。

SAML との比較

観点 OIDC SAML 2.0
データ形式 JSON / JWT XML
用途 Web / モバイル エンタープライズ SSO
実装の複雑さ 低い 高い
モバイル対応 適している 不向き

新規プロジェクトでは OIDC が推奨される。

OpenID Connect については関連書籍でも詳しく扱われている。

関連用語