ホーム/セキュリティ/認証・認可の方式/ OpenID Connect

製品プロフィール

OpenID Connect

認証プロトコル（OAuth 2.0 上）

OAuth 2.0 の上に「誰がログインしたか（認証）」を足した層。ID トークンで本人情報を安全に伝える、ソーシャルログインの実体。

3つの要点

TL;DR

OAuth に「本人確認」を足した認証の層。
ID トークン(JWT)で誰かを安全に検証できる。
Web/モバイルのソーシャルログインならこれ。

基本情報

仕様と立ち位置

製品・技術の概要OpenID ConnectOAuth 2.0 の上に「誰がログインしたか（認証）」を足した層。ID トークンで本人情報を安全に伝える、ソーシャルログインの実体。
種別: 認証プロトコル（OAuth 2.0 上）
目的: 認証（本人確認）
トークン/形式: ID トークン（JWT）
最大の強み: OAuth に認証を標準化して追加ID トークン(JWT)で本人を検証
代表的な用途: ソーシャルログインSSO（シングルサインオン） / モダンな Web/モバイル認証

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

OAuth に認証を標準化して追加
ID トークン(JWT)で本人を検証
ソーシャルログインの定番

事前に確認する条件

考慮すべき点

OAuth の理解が前提
トークン検証の実装が必要

詳しい解説

もっと詳しく

どんな仕組みか

OpenID Connect（OIDC）は、OAuth 2.0 の上に「本人確認（認証）」を足した仕組みです。OAuth 2.0 だけでは「何にアクセスしてよいか」しか分かりませんが、OIDC は「誰がログインしたのか」をきちんと伝えられます。

「Google でログイン」「Apple でログイン」といったソーシャルログインの認証部分は、この OIDC が担っています。

横にスクロール

OIDCでは認可コードの交換とIDトークンの検証を分け、認証結果とAPI権限も用途別に扱います。

どう動くのか

認証が成功すると、認可サーバー（OIDC では IdP：Identity Provider とも呼ぶ）はアクセストークンに加えて ID トークンを発行します。ID トークンは JWT 形式で、ログインしたユーザーの識別子や発行元などのクレームを含みます。

ID トークン(JWT)の主なクレーム
- iss: 発行者(どの IdP か)
- sub: ユーザーの一意な識別子
- aud: 受け取るべきアプリ(クライアント ID)
- exp: 有効期限
- nonce: リプレイ防止用の値

アプリは ID トークンの署名と内容を検証し、「確かにこの IdP が認証したユーザーだ」と確認します。ユーザーの追加属性は UserInfo エンドポイントから取得でき、openid に加えて profile・email などのスコープで取得範囲を指定します。IdP の設定は ディスカバリ（.well-known/openid-configuration） と公開鍵（JWKS）で自動取得できるのも特徴です。

他の方式との違い

OAuth 2.0 は認可（アクセス委譲）、OIDC は認証（本人確認）が主目的です。OIDC は OAuth 2.0 を土台にしているため、認証と認可を一貫した流れで扱えます。

観点	OIDC	SAML
形式	JSON / JWT	XML
世代・相性	モバイル・SPA・API に好適	歴史が長く企業 SaaS に浸透
土台	OAuth 2.0 上の認証層	独立したフェデレーション仕様
取得情報	ID トークン＋UserInfo	SAML アサーション

OAuth 2.0：アクセストークンで「権限」を渡す
OIDC：ID トークンで「誰か」を伝える

使いどころ・注意点

自前で ID とパスワードを管理せず、外部 IdP に認証を任せたい場面に向きます。ソーシャルログインや、企業向けの SSO 基盤として広く使われます。

ID トークンは必ず検証する

ID トークンは、署名（IdP の公開鍵）に加えて発行元（iss）、対象アプリ（aud）、有効期限（exp）、そして nonce を検証してから信頼します。検証を省くと、なりすましたトークンやリプレイを受け入れてしまう恐れがあります。フローは認可コード＋PKCE を用い、アクセストークン（認可用）と ID トークン（認証用）の役割を混同しないことが重要です。

総じて OIDC は、OAuth 2.0 の上に標準化された認証層を載せることで、外部 IdP への認証委譲とシングルサインオンを安全に実現する現代的な方式です。

実装・運用の視点

OpenID Connectを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

ソーシャルログイン

比較で見る軸

種別: 認証プロトコル（OAuth 2.0 上） / 目的: 認証（本人確認） / トークン/形式: ID トークン（JWT）

導入後に効く点

ID トークン(JWT)で本人を検証

先に潰すリスク

OAuth の理解が前提

数字・仕様の読み方

種別: 認証プロトコル（OAuth 2.0 上）
目的: 認証（本人確認）
トークン/形式: ID トークン（JWT）

判断チェックリスト

自社の用途が「ソーシャルログイン / SSO（シングルサインオン）」に近いか確認する。
強みである「OAuth に認証を標準化して追加」が本当に評価軸になるか確認する。
注意点の「OAuth の理解が前提」を運用で吸収できるか確認する。
公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

ソーシャルログインSSO（シングルサインオン）モダンな Web/モバイル認証

参考: 公式サイト

向いている用途

こんな用途に向く

ソーシャルログインSSO（シングルサインオン）モダンな Web/モバイル認証

公式サイト