OIDC（OpenID Connect）の概要と特徴
概要
OAuth 2.0の認可プロトコルの上に構築された、ID連携のための認証（Authentication）レイヤー
ユーザーが外部サービス（Google, LINE等）のIDを使用して、別のサービスへログインする仕組み
JSON Web Token (JWT) 形式のIDトークンを利用した、標準化されたアイデンティティ・プロトコル
主な特徴
相互運用性 (Interoperability)：異なるシステム間でも統一された手法でユーザー情報の受け渡しが可能
認証の外部委託：信頼できるプロバイダーに認証を任せることで、自社でのパスワード保持を回避
スコープによる制御：ユーザーの同意に基づき、名前やメールアドレス等の取得範囲を限定
分類
プロトコルの位置付け
Authentication Layer：ユーザーが誰であるかを確認する認証層
Identity Layer：OAuth 2.0（認可）を拡張し、ユーザープロファイルを扱うための拡張仕様
上位概念・下位概念
上位概念
SSO (Single Sign-On)：一度の認証で複数のシステムを利用可能にする仕組み
Federated Identity：組織を超えてアイデンティティ情報を共有する概念
下位概念・構成要素
ID Token：ユーザー属性を含む署名付きトークン（JWT形式）
UserInfo Endpoint：追加のユーザー情報を取得するためのAPI
メリット
セキュリティ
パスワード情報の非保持：サービス側でパスワードを管理せず、漏洩リスクを低減
検証の容易さ：デジタル署名により、トークンが改ざんされていないことを容易に検証可能
利便性
ユーザー体験の向上：新規アカウント作成の手間を省き、既存IDでのクイックログインを実現
開発コストの削減：標準仕様に従うことで、独自の認証基盤を構築する工数を圧縮
デメリット
依存性と複雑性
外部サービスへの依存：IDプロバイダーのダウンタイム時に自社サービスもログイン不可となるリスク
仕様の理解度：OAuth 2.0との違いやトークン検証手順など、実装にあたって正しい理解が不可欠
既存との比較
SAML 2.0
SAMLはXMLベース。OIDCはJSONベースで軽量
OIDCはモバイルアプリやWebアプリとの親和性が高く、現代のAPIベースの開発に最適
OAuth 2.0
OAuth 2.0は「権限の譲渡（認可）」のみを定義。誰がログインしたかの特定（認証）には不十分
OIDCはOAuth 2.0にIDトークンの仕組みを追加し、認証を可能に拡張
競合
代替手段
独自実装（ID/Pass）：自社データベースでメールアドレスとパスワードを管理する手法
WebAuthn (Passkeys)：パスワードを使わずデバイスの生体認証などを利用する最新規格
導入ポイント
選定基準
ソーシャルログイン実装：一般消費者向けアプリで登録率を向上させたい場合
B2B SaaS連携：Azure ADやOktaなどのID管理製品と連携し、企業ユーザーのSSOを実現したい場合
注意点
実装上のリスク
トークンの有効期限管理：IDトークンの有効期間を適切に設定し、漏洩時の被害を最小化
暗号化と署名検証：公開鍵を用いた署名検証をスキップせず、確実に実施する実装の徹底
今後
展望
Passwordlessの普及：OIDCとPasskeysを組み合わせた、より強固で便利な認証体験の普及
分散型アイデンティティ (DID)：特定の企業に依存しない、自己主権型の身分証明技術との統合
関連キーワード
- OAuth 2.0
- JWT (JSON Web Token)
- IdP (Identity Provider)
- RP (Relying Party)
- ID Token
- Access Token
- Scope
- SSO (Single Sign-On)
- Claims
- UserInfo Endpoint
