OAuth 2.0 と OpenID Connect (OIDC) の違い — 認可と認証

Q: Q. 「Google でログイン」 を実装するなら OAuth と OIDC のどっち?

A. OIDC です。「Google でログイン」 で得たいのは 「このユーザーが誰か」 という 認証 なので OIDC が正解。アクセストークンと一緒に ID トークンが返ってくるので、ID トークンを検証してユーザー識別、必要なら同時にアクセストークンで Google API を呼ぶ の二段使いが標準。

Q: Q. JWT ってどう違うんですか?

A. JWT は形式、OAuth/OIDC はプロトコル です。JWT は 「署名付きの JSON 文字列」 の汎用フォーマットで、「OIDC の ID トークン」 が代表的な利用例。OAuth 2.0 のアクセストークンは 「JWT である必要は無く、不透明文字列でも OK」 です。「JWT を使うかどうか」 は実装の選択。

Q: Q. アクセストークンの保管場所はどこが安全ですか?

A. HttpOnly + Secure + SameSite Cookie が現代的な推奨です。「localStorage」 は XSS でアクセス可能なので推奨されません。SPA で API を叩くなら 「バックエンドが Cookie でトークンを保持し、フロントには Cookie だけ自動送信される」 構成が安全(BFF パターン)。

Q: Q. PKCE は本当に必須ですか?

A. 新規実装ではほぼ必須です。元々は 「スマホアプリ・SPA など秘密鍵を持てないクライアント」 向けでしたが、現在は 認可コード横取り攻撃の対策として、すべてのフローで推奨 されています。サーバサイド Web アプリでも PKCE を使うのが現代の標準です。

Q: Q. リフレッシュトークンはどう扱うべき?

A. バックエンドで安全に保管。リフレッシュトークンは長期間有効なので、クライアントには露出させずバックエンドが管理 が安全。「Token Rotation(使うたびに新しいリフレッシュトークンを発行し、古いものを無効化)」 を有効化すると、漏洩時の被害を最小化できます。

Q: Q. SAML との関係は?

A. SAML は古い世代の認証プロトコルです。「XML ベース」 で 「エンタープライズの SSO」 で広く使われていますが、新規実装は OIDC が選ばれることが多いです。「Microsoft Entra ID(旧 Azure AD)」 や 「Okta」 は SAML と OIDC の両方をサポートし、「既存システムは SAML、新規は OIDC」 の混在構成も多い。

Q: Q. OAuth 2.1 ってどう違いますか?

A. OAuth 2.0 のベストプラクティスを統合した次世代版 です。「Implicit Flow / Password Grant の廃止」 「PKCE の標準化」 「Refresh Token Rotation の推奨」 など、現代の運用で推奨されているプラクティスを規格に組み込んだ もの。「OAuth 2.0 で PKCE + Authorization Code + Token Rotation」 をやっていれば、ほぼ OAuth 2.1 に準拠していることになります。

先に要点

OAuth 2.0 = 認可(Authorization)プロトコル。「ユーザーが、ある API へのアクセスを第三者アプリに許可する」ための仕組み。「このアプリにあなたの Google Drive へアクセスを許可しますか?」がまさにこれ。
OpenID Connect (OIDC) = OAuth 2.0 の上に乗っかった認証(Authentication)プロトコル。「このユーザーが誰か」を確認するための仕組み。「Google でログイン」「Microsoft でログイン」のような ソーシャルログイン はほとんどがこれ。
区別の核は トークンの種類。OAuth 2.0 が発行するのは アクセストークン(API 呼び出し用)、OIDC が追加で発行するのは ID トークン(ユーザー識別情報を含む JWT)。「ID トークンの中身を見ればユーザーが分かる」のが OIDC の本質。
混同による事故の典型は OAuth のアクセストークンを認証に使ってしまう。「アクセストークンを取れる = ユーザーが本人」と勘違いし、別アプリ向けのトークンで誰でも他人になりすませる脆弱性が生まれる。「認証なら OIDC、認可なら OAuth 2.0」と明確に分ける。
実装は Auth0 / AWS Cognito / Okta / Firebase Auth / Google Identity / Microsoft Entra ID のようなマネージド IdP に任せるのが現代の標準。「自前で OAuth/OIDC サーバを書く」は専門家以外は事故ると割り切る。

「Google でログイン」ボタンを実装する時、「OAuth 2.0 のドキュメントを読むべきか、OpenID Connect のドキュメントを読むべきか分からない」 ── これは認証・認可周りで誰もが当たる壁です。

混乱の原因は、OAuth 2.0 と OIDC が「似た仕組みで違う目的に使われている」こと。「OAuth 2.0 = API への認可」、「OIDC = ユーザーの認証」と役割を分けて理解すれば、ドキュメントを読む順番もコードを書く判断もスッキリします。

この記事では、両者の 違い・トークンの種類・ユースケース別の使い分け・混同による事故 を、「これから認証/認可を実装する人」向けに整理します。

まず役割を一言で

両者の核心を表にまとめます。

項目	OAuth 2.0	OpenID Connect (OIDC)
主な目的	認可(API へのアクセス許可)	認証(ユーザーが誰か確認)
位置づけ	独立したプロトコル	OAuth 2.0 の上に乗った拡張
発行するトークン	アクセストークン(+ リフレッシュトークン)	OAuth 2.0 のトークン + ID トークン(JWT)
ユーザー情報	原則として含まない	ID トークンに sub / email / name など
典型ユースケース	「あなたの Google Drive にアクセスを許可しますか?」	「 Google でログイン」のソーシャルログイン全般
標準化団体	IETF (RFC 6749 / 6750)	OpenID Foundation

要するに OIDC は OAuth 2.0 の「認証用バリエーション」として作られた と理解すると、ドキュメント間の関係が見えてきます。

OAuth 2.0 は「アクセス権を委譲する」仕組み

OAuth 2.0 は元々 ユーザーがパスワードを第三者アプリに渡さずに、特定 API へのアクセスを委譲する ために設計されました。

登場人物

「リソースオーナー(ユーザー)」「クライアント(第三者アプリ)」「認可サーバー(Google/Microsoft など)」「リソースサーバー(API 本体)」の4者。`ユーザーが Google に許可を与え、Google が認可サーバとしてアプリに「アクセストークン」を渡し、アプリはそれで API を呼ぶ」流れ。

本質はアクセス権の委譲

「パスワードを渡す」のではなく、「期限付き・スコープ限定のアクセスを許可する」のが核。「カレンダーへの読み取りだけ許可」「48 時間だけ有効」のように 権限を細かく区切れる。

アクセストークン

API リクエストに付与する 不透明なトークン(opaque token) が標準。「アクセストークンの中身は API 提供者しか分からない」のが原則(JWT 形式の場合もあるがオプション)。リソースサーバはこれを検証して API を返す。

スコープでアクセス範囲を指定

「 scope=drive.readonly」「scope=calendar.events」のように 「どこまでアクセス可能か」を指定。「過剰なスコープを取らない」のが安全設計の基本。

OIDC は「誰かを確認する」仕組み

OIDC は OAuth 2.0 を 認証用に拡張 したもので、「ユーザーが本当にこの人物か」を確認するためのトークンを追加しています。

ID トークンが核

OIDC の最大の追加要素は ID トークン(JWT 形式)。「誰が」「いつ」「どの IdP で」「どのアプリにログインしたか」を 署名付きで証明する。アプリは 中身を検証するだけでユーザーを識別 できる。

標準クレーム

ID トークンには sub(一意のユーザー ID)」「iss(発行者)」「aud(発行先アプリ)」「exp(有効期限)」「email」「name」 `picture などの標準クレームが含まれる。「 sub + iss」の組み合わせで「どの IdP の誰か」を一意に特定できる。

UserInfo エンドポイント

ID トークンに含まれない追加情報(プロフィール、メール詳細など)が必要な時は、/userinfo エンドポイント をアクセストークンで叩いて取得する。「ID トークンを軽く保ち、必要な時に UserInfo」が一般的な使い分け。

discovery と JWKS

「 /.well-known/openid-configuration」で IdP のエンドポイント情報が取得できる(discovery)。「/.well-known/jwks.json」で署名検証用の公開鍵が取得できる(JWKS)。ライブラリに任せれば自動で取得・キャッシュしてくれる。

トークンの種類の整理

両者で出てくる主なトークンを一度整理します。

トークン	誰が発行	何に使うか	形式
アクセストークン	OAuth 2.0 / OIDC 認可サーバ	API リクエストの認可	不透明 or JWT(実装依存)
リフレッシュトークン	OAuth 2.0 / OIDC 認可サーバ	アクセストークンの再発行	長期間有効、安全に保管
ID トークン	OIDC のみ	ユーザーが誰かを証明	JWT(署名付き、必ず検証)
認可コード	OAuth 2.0 / OIDC 認可サーバ	アクセストークンと交換する一時コード	短時間で失効、一度使うと無効

「ID トークンは誰か証明、アクセストークンは API 呼び出し」と覚えると整理しやすいです。

認可フローの選び方

OAuth 2.0 / OIDC には複数の フロー(grant type) があり、用途で使い分けます。「どれを選ぶか」で混乱しやすいので主要パターンを整理します。

Authorization Code + PKCE(推奨デフォルト)

「認可コードを取得 → トークンと交換」の標準フロー。PKCE(Proof Key for Code Exchange) を併用することで、「スマホアプリ」「SPA」のような秘密鍵を持てないクライアントでも安全に使える。現代では Web / SPA / モバイルすべてこれが推奨。

Client Credentials

「バックエンド同士の認証(マシン to マシン)」で使う。ユーザーが介在しない「API キーの代替」用途。「バッチ処理が外部 API を叩く」のような サーバ to サーバ の通信に適している。

Implicit / Resource Owner Password(非推奨)

Implicit Flow は セキュリティ問題で廃止傾向。Password Grant も パスワードをクライアントに渡す古い設計 として非推奨。「既存システムが使っていれば移行を計画」、新規は使わない。

Device Authorization Grant

「テレビ・スマートデバイス・CLI など、画面入力が不自由な機器」向けのフロー。「PC でコードを入力して認証」する Netflix のテレビアプリのような体験。

「新規プロジェクトはほぼ常に Authorization Code + PKCE で OK」と覚えておけば、9 割の判断は迷いません。

混同が引き起こす事故パターン

OAuth と OIDC の境界が曖昧なまま実装すると、典型的な脆弱性パターンに陥ります。

アクセストークンを認証に使う

「 Google のアクセストークンを受け取れた = ユーザーが本人だ」という誤った仮定で実装すると、別アプリ向けに発行されたトークンで誰でも他人になりすませる重大脆弱性が生まれる(「OAuth Confused Deputy」)。認証なら必ず ID トークンの aud(audience)を検証 が原則。

ID トークンの署名検証を怠る

「 ID トークンの中身を見るだけ」で署名検証しないと、攻撃者が偽造した JWT を信じてしまう。JWKS から公開鍵を取得して必ず署名検証、「iss(発行者)」「aud(発行先)」「exp(有効期限)」も検証する。

アクセストークンを長期間保管

「 localStorage に永続化して再ログイン無しにする」のような実装は、XSS 一発で全部漏れる。短命のアクセストークン + 安全に保管したリフレッシュトークン、または「HttpOnly Cookie + サーバセッション」の構成が安全。

過剰なスコープを取る

「必要ない権限まで scope に含める」と、「データ漏洩時の被害が広がる」し、「ユーザーが同意画面で警戒する」。最小スコープの原則で、「本当に必要なものだけ」を要求する。

「認証なら OIDC + ID トークン検証、認可なら OAuth 2.0 + スコープ最小化」を 意識の出発点 にすると、これらの事故を構造的に避けられます。

自前実装 vs マネージド IdP

「 OAuth/OIDC サーバを自前で書く」のは推奨されません。マネージド IdP に任せるのが現代の標準です。

読み込み中...

特に 個人開発 / 中小規模 SaaS では、OAuth 2.0 対応のマネージド IdP を選ぶことが、「セキュリティ品質を上げつつ実装工数を下げる」ベストプラクティスです。

OAuth 2.0 と OIDC に関するよくある質問

Q. 「Google でログイン」を実装するなら OAuth と OIDC のどっち?

A. OIDC です。「Google でログイン」で得たいのは「このユーザーが誰か」という認証なので OIDC が正解。アクセストークンと一緒に ID トークンが返ってくるので、ID トークンを検証してユーザー識別、必要なら同時にアクセストークンで Google API を呼ぶ の二段使いが標準。

Q. JWT ってどう違うんですか?

A. JWT は形式、OAuth/OIDC はプロトコル です。JWT は「署名付きの JSON 文字列」の汎用フォーマットで、「OIDC の ID トークン」が代表的な利用例。OAuth 2.0 のアクセストークンは「JWT である必要は無く、不透明文字列でも OK」です。「JWT を使うかどうか」は実装の選択。

Q. アクセストークンの保管場所はどこが安全ですか?

A. HttpOnly + Secure + SameSite Cookie が現代的な推奨です。「localStorage」は XSS でアクセス可能なので推奨されません。SPA で API を叩くなら「バックエンドが Cookie でトークンを保持し、フロントには Cookie だけ自動送信される」構成が安全(BFF パターン)。

Q. PKCE は本当に必須ですか?

A. 新規実装ではほぼ必須です。元々は「スマホアプリ・SPA など秘密鍵を持てないクライアント」向けでしたが、現在は 認可コード横取り攻撃の対策として、すべてのフローで推奨 されています。サーバサイド Web アプリでも PKCE を使うのが現代の標準です。

Q. リフレッシュトークンはどう扱うべき?

A. バックエンドで安全に保管。リフレッシュトークンは長期間有効なので、クライアントには露出させずバックエンドが管理 が安全。「Token Rotation(使うたびに新しいリフレッシュトークンを発行し、古いものを無効化)」を有効化すると、漏洩時の被害を最小化できます。

Q. SAML との関係は?

A. SAML は古い世代の認証プロトコルです。「XML ベース」で「エンタープライズの SSO」で広く使われていますが、新規実装は OIDC が選ばれることが多いです。「Microsoft Entra ID(旧 Azure AD)」や「Okta」は SAML と OIDC の両方をサポートし、「既存システムは SAML、新規は OIDC」の混在構成も多い。

Q. OAuth 2.1 ってどう違いますか?

A. OAuth 2.0 のベストプラクティスを統合した次世代版 です。「Implicit Flow / Password Grant の廃止」「PKCE の標準化」「Refresh Token Rotation の推奨」など、現代の運用で推奨されているプラクティスを規格に組み込んだもの。「OAuth 2.0 で PKCE + Authorization Code + Token Rotation」をやっていれば、ほぼ OAuth 2.1 に準拠していることになります。

まとめ

OAuth 2.0 と OpenID Connect (OIDC) は、OAuth 2.0 = 認可、OIDC = 認証 という役割の違いさえ押さえれば、ドキュメントとコードの読み解きが一気に楽になります。

「認証に使うなら必ず OIDC + ID トークン検証」、「API への認可なら OAuth 2.0 + スコープ最小化」、「実装はマネージド IdP に任せる」の 3 原則を出発点にすれば、混同による脆弱性をほぼ避けられます。「OWASP Top 10 の A07(認証の失敗)」への対策としても、この理解は強い武器になります。

参考リンク

IETF: RFC 6749 - OAuth 2.0 Authorization Framework
OpenID Foundation: OpenID Connect Core 1.0
IETF: OAuth 2.1 (draft)
Auth0: Intro to OAuth 2.0
AWS: Amazon Cognito