認証結果を標準化する
ID Tokenのclaimsによって、誰が、どのProviderで、いつ認証されたかをClientへ伝えます。
Specification
OAuth 2.0の上に認証レイヤーを追加し、ID Token、UserInfo、標準Claimsによる本人確認を定義します。
Overview
OpenID ConnectはOAuth 2.0の上に本人確認の仕組みを追加する認証仕様です。OAuthのアクセストークンはAPIを利用するための許可証ですが、それだけでは『ログインした人が誰か』をClientが安全に判断できません。
OIDCでは認可リクエストへopenid scopeを追加し、認証結果を署名付きJWTであるID Tokenとして受け取ります。Clientは署名だけでなく、issuer、audience、有効期限、nonceを検証し、自分のために発行された新しい認証結果であることを確認します。
Purpose and responsibilities
ID Tokenのclaimsによって、誰が、どのProviderで、いつ認証されたかをClientへ伝えます。
Clientごとにパスワードを管理せず、信頼するOpenID Providerへ本人確認を集約できます。
UserInfo Endpointと標準claimsにより、sub、name、emailなどの受け渡し方法を統一します。
Key concepts
Security considerations
仕様を実装するときは、正常系の通信だけでなく、値のすり替え、再利用、漏えいが起きた場合も考えます。
ID Tokenはアクセストークンの代わりにAPIへ送らず、Clientが認証結果を確認するために使います。
JWKSで署名を検証し、iss、aud、exp、iat、nonceを用途に応じて確認します。
subをユーザーの安定した識別子として使い、表示名やemailだけでアカウントを結び付けません。
UserInfoを利用する場合、応答のsubがID Tokenのsubと一致することを確認します。
Interactive flows
OAuth 2.0へ本人確認を追加し、署名付きIDトークンからユーザーの認証結果を安全に受け取ります。
図を再生する →OpenID Connect Core 1.0 · Interactive flowOpenID Connect Hybrid FlowAuthorization Endpointからcodeと一部トークンを組み合わせて返し、フロントチャネルとバックチャネルを併用する高度なOIDCフローです。
図を再生する →OpenID Connect Core 1.0 · LegacyOpenID Connect Implicit Flow — LegacyIDトークンやアクセストークンをAuthorization Endpointから直接返す旧OIDCフローです。現在はCode + PKCEを優先します。
図を再生する →Position and relationship
OIDC CoreはOAuth 2.0 Authorization Code Flowを利用します。DiscoveryはProviderのEndpointや機能を公開し、Dynamic RegistrationはClient登録を標準化します。CIBAはブラウザリダイレクトを使わないOIDCの追加認証フローです。
Other specifications