// シス担のミカタ
シングルサインオン・ID連携

OpenID Connect おーぷんあいでぃーこねくと

シングルサインオンOAuth 2.0IDトークン認証フェデレーションJWT
OpenID Connectについて教えて

簡単に言うとこんな感じ！

「Googleアカウントでログイン」ってボタン、見たことあるよね？あれを実現する仕組みがOpenID Connectだよ。「あなたが誰か」を別のサービスに証明してもらう、いわば”デジタル身分証明書の仲介役”なんだ！

OpenID Connectとは

OpenID Connect（OIDC） は、インターネット上でユーザーの「本人確認（認証）」を安全に行うための標準プロトコルです。2014年にリリースされ、現在では世界中のWebサービスやアプリで広く使われています。「Googleでログイン」「Appleでサインイン」「Microsoftアカウントでログイン」といった機能は、すべてこのOpenID Connectをベースに実装されています。

OpenID Connectは、OAuth 2.0という「認可（何をしてよいか）」の仕組みの上に「認証（誰であるか）」の機能を追加したものです。OAuth 2.0だけでは「このユーザーが誰なのか」を厳密に確認する手段がなかったため、その不足を補う形で設計されました。結果として、「認証」と「認可」を一度の操作でまとめて扱える強力な仕組みになっています。

実務上は、社員が複数の業務システムに同じアカウントでログインできるシングルサインオン（SSO） の基盤として採用されるケースが多いです。一度の認証で複数システムを使えるため、パスワード管理の負担軽減やセキュリティ強化に直結します。

OpenID Connectの核心：登場人物と仕組み

OpenID Connectには3つの登場人物がいます。この関係を押さえると全体が見えてきます。

役割英語名具体例
エンドユーザーEnd Userログインしようとしている人（あなた）
クライアント（RP）Relying Partyログインしたいアプリ・サービス
認証サーバー（OP）OpenID ProviderGoogle / Microsoft / 社内IdP など

認証の流れ（シーケンス）

ユーザー        クライアント(RP)        認証サーバー(OP)
   |                  |                        |
   |--「ログイン」-->  |                        |
   |                  |---認証リクエスト------> |
   |<---------認証画面リダイレクト-------------|
   |---ID/PW入力---------------------------->  |
   |                  |<---認可コード------------|
   |                  |---コード + 秘密鍵------> |
   |                  |<---IDトークン + アクセストークン--|
   |<--ログイン完了---|                        |

IDトークン（JWT）が証明書の本体

認証が成功すると、認証サーバーは IDトークン を発行します。これは JWT（JSON Web Token） という形式の電子署名付き文書で、以下の情報が含まれます。

フィールド名内容例
subユーザーの一意ID"1234567890"
name氏名"山田 太郎"
emailメールアドレス"taro@example.com"
iss発行者（認証サーバー）"https://accounts.google.com"
aud受取人（クライアント）"my-app-client-id"
exp有効期限（UNIXタイム）1712620800

覚え方：「認証はOIDC、認可はOAuth」

  • OAuth 2.0 → 「何をしてよいか（権限）」を委任する → 認可
  • OpenID Connect → 「誰であるか（身元）」を確認する → 認証

よく混同されますが、「OAuth だけではログインに使えない」という点が重要です。OIDCはOAuthの上にIDトークンという”顔写真付き身分証”を追加した、と覚えましょう。

歴史と背景

  • 2005年 — OpenID 1.0 が登場。URLを使って身元証明する仕組みだったが、普及に課題あり
  • 2007年 — OpenID 2.0 に改良。Blogや個人サイトでの利用が広がる
  • 2012年 — OAuth 2.0 が RFC 6749 として標準化。「認可」専用の枠組みが確立
  • 2014年2月 — OpenID Connect 1.0 が OpenID Foundation により正式リリース。OAuth 2.0 ベースに刷新され、モバイル・クラウド時代に対応
  • 2015〜 — Google・Microsoft・Salesforce 等の大手が一斉に採用。事実上の業界標準に
  • 2020年代 — ゼロトラストセキュリティの文脈でアイデンティティ管理の中核プロトコルとして再評価

OAuth 2.0 との関係と比較

OpenID ConnectとOAuth 2.0はよく混同されます。SVG図解で関係性を整理します。

OAuth 2.0（認可フレームワーク） 「誰が・何を・どこまで許可するか」を定める OpenID Connect 1.0（OIDCレイヤー） OAuth 2.0 に「本人確認（認証）」を追加 IDトークン（JWT） ・sub（ユーザーID） ・name / email ・iss / aud / exp ・電子署名付き アクセストークン ・APIアクセスに使う ・スコープで権限制御 ・有効期限あり （OAuth 2.0 の機能） ＋ 同時に 発行される → 認証（誰か確認） → 認可（何を許可）

主なOpenIDプロバイダー（OP）の比較

プロバイダー特徴主な用途
Google最も普及。Gmail/GWSと連携コンシューマー・SaaS
Microsoft Entra IDActive Directoryと統合企業・Microsoft 365環境
Appleプライバシー重視。メール隠蔽機能ありiOSアプリ
Okta / Auth0専業IdP。カスタマイズ性が高いエンタープライズSSO
Keycloakオープンソース。自社構築向けオンプレミス・プライベートクラウド

関連する規格・RFC

規格・RFC番号内容
RFC 6749OAuth 2.0 認可フレームワーク（OIDCの土台）
RFC 7519JWT（JSON Web Token）の仕様
RFC 7517JWK（JSON Web Key）：署名検証用の公開鍵形式
RFC 7636PKCE（Proof Key for Code Exchange）：モバイル向けセキュリティ強化
OpenID Connect Core 1.0OIDCの主要仕様（OpenID Foundation策定）
OpenID Connect Discovery 1.0プロバイダーの設定情報を自動取得する仕様

関連用語