OAuth 2.0とOIDCの違いとは？認可と認証の仕組みを徹底比較

PR Amazonのアソシエイトとして、ITナレッジライフは適格販売により収入を得ています。

記事の文字数：6,203

OAuth 2.0とOpenID Connect（OIDC）の違いを初心者にもわかりやすく徹底解説。認可と認証の根本的な違いや、なぜOAuth単体でログイン機能を作ってはいけないのか、IDトークン（JWT）やアクセストークンの役割、認可コードフロー＋PKCEの仕組みまで図解で詳しく紹介します。

公開日 2026/11/12

最終更新 2026/11/12

ITエンジニアにお勧めの本 ↗

OAuth 2.0 と OIDC の違いまとめ【比較表】

まずは、OAuth 2.0 と OpenID Connect（OIDC）の主要な相違点を比較表で整理します。

比較項目	OAuth 2.0	OpenID Connect（OIDC）
主な目的	認可（Authorization）リソースへのアクセス権限委譲	認証（Authentication）ユーザーの本人確認と属性情報取得
位置づけ	認可フレームワーク（RFC 6749）	OAuth 2.0 の上に構築された認証レイヤー（プロトコル）
発行されるトークン	アクセストークン（API呼び出し用）リフレッシュトークン	IDトークン（本人確認用）アクセストークンリフレッシュトークン
トークンのフォーマット	規定なし（不透明な文字列でもJWTでも自由）	JWT（JSONJSON [ジェイソン]JavaScript Object Notation。軽量データ交換フォーマット Web Token）に厳密に標準化
対象者（Audience）	リソースサーバー（API）が検証して消費する	クライアント（Web/アプリ）が検証して消費する
追加エンドポイント	Token エンドポイント Authorization エンドポイント	上記に加え、 UserInfo エンドポイント Discovery（`/.well-known/openid-configuration`）
代表的なスコープ	サービス独自のスコープ（例: `read:mail`）	必須スコープ `openid` 、`profile`、`email` 等
仕様策定団体	IETF（Internet Engineering Task Force）	OpenID Foundation（OIDF）
代表的な用途	「自作アプリからGoogleドライブのファイルを操作する」	「Googleアカウントを使ってWebサイトに新規登録・ログインする」

このように、OIDC は OAuth 2.0 を置き換える競合規格ではなく、 「OAuth 2.0 の認可の枠組みの上に、認証機能を乗せた拡張仕様」 です。

1
┌────────────────────────────────────────────────────────┐
2
│  OpenID Connect (OIDC) - 認証プロトコル (IDトークン / UserInfo) │
3
├────────────────────────────────────────────────────────┤
4
│  OAuth 2.0 - 認可フレームワーク (認可コード / アクセストークン)  │
5
├────────────────────────────────────────────────────────┤
6
│  HTTP / HTTPS / TLS                                    │
7
└────────────────────────────────────────────────────────┘

OAuth 2.0 とは？【認可（アクセス権限の委譲）のフレームワーク】

OAuth 2.0 は、サードパーティアプリケーションに対して、 ユーザーのパスワードを教えることなく、限定されたリソースへのアクセス権を委譲するためのフレームワーク（RFC 6749） です。

OAuth 2.0 が生まれた背景

OAuth が登場する以前、外部サービスと連携するには「ユーザーのログインIDとパスワード」をサードパーティアプリに直接入力させる必要がありました（例: カレンダーアプリにGoogleアカウントのパスワードを渡す）。

しかし、この方式には以下のような重大なセキュリティ問題がありました。

パスワード漏洩のリスク: サードパーティアプリが悪意を持っていたりハッキングされたりすると、ユーザーの本パスワードが流出する。
権限の過大付与: パスワードを渡すと、メール送信やアカウント削除など、そのアカウントが持つ全権限がアプリに渡ってしまう。
失効の難しさ: アプリの利用をやめたい場合、ユーザー自身の本パスワードを変更するしかなく、連携していた他の全サービスにも影響する。

OAuth 2.0 は、この問題を解決するために設計されました。ユーザーは認可サーバー上で安全に同意を行い、クライアントアプリにはパスワードではなく 「アクセストークン（Access Token）」 のみが渡されます。

OAuth 2.0 の4つの役割（Roles）

OAuth 2.0 では、システムを以下の4つのエンティティ（役割）に分けて定義しています。

リソースオーナー（Resource Owner）: データやアカウントの所有者（通常はエンドユーザー）。
クライアント（Client）: ユーザーのリソースにアクセスしたいサードパーティ製アプリケーション（Webサイトやスマホアプリ）。
認可サーバー（Authorization Server）: リソースオーナーの同意を得て、クライアントにアクセストークンを発行するサーバー。
リソースサーバー（Resource Server）: 保護されたリソース（API）を保持し、有効なアクセストークンを受け取ってデータを返すサーバー。

アクセストークンの役割

アクセストークンは、 「ホテルのルームキー」 に例えられます。

ホテルのルームキーを持っている人は、その部屋の鍵を開けて入室できます。しかし、ルームキー自体には「宿泊者の氏名」「住所」「年齢」といった本人確認情報は書かれていません。ドアの鍵穴（リソースサーバー）は、「このキーが有効な権限を持っているかどうか」だけをチェックします。

同様に、OAuth 2.0 のアクセストークンは 「APIを呼び出す権限」 を表す鍵であり、「今操作している人が誰か」を証明するものではありません。

なぜ OAuth 2.0 単体で「ログイン（認証）」を作ってはいけないのか？【擬似認証の罠】

Web開発の現場で非常に多い誤解が、 「OAuth 2.0 でアクセストークンが取れたから、このユーザーをログイン状態にしよう」 という実装です。

これを 「擬似認証（Pseudo-authentication）」 と呼び、深刻なセキュリティ脆弱性を引き起こすリスクがあります。

理由1：アクセストークンは「誰向け」に発行されたか検証できない

OAuth 2.0 の仕様では、アクセストークンの形式や中身について厳密な規定がありません。多くの実装では単なるランダムな不透明文字列（Opaque Token）が使われます。

そのため、クライアントアプリがアクセストークンを受け取っても、以下の重要な事実を検証できません。

このトークンは 本当に自社アプリ（Client A）向け に発行されたのか？（他の悪意あるアプリ Client B 向けに発行されたものではないか？）
このトークンを発行したユーザーは、 今まさにブラウザの前に存在して認証を完了したのか？

理由2：トークン差し替え攻撃（Token Substitution Attack）

攻撃者が自前の悪意あるアプリ（Client B）を用意し、被害者から正規の認可を得てアクセストークンを入手したとします。

もしターゲットのWebサイト（Client A）が「アクセストークンを送信してAPIからユーザーIDが取れたらログイン成功」という実装をしていた場合、攻撃者は Client B 向けに発行されたアクセストークンを Client A のログインAPIに差し替えて送信します。

Client A はアクセストークンを使ってリソースサーバーに問い合わせ、「ユーザーID: 12345」という結果を受け取ると、攻撃者を被害者（ユーザー12345）としてログインさせてしまいます。これが 「トークン差し替え攻撃」 です。

sequenceDiagram autonumber actor Attacker as 攻撃者 participant FakeApp as 悪意あるアプリ（Client B） participant Victim as 被害者 participant AuthServer as 認可サーバー participant TargetApp as 対象Webサイト（Client A） Victim->>FakeApp: 悪意あるアプリを利用 FakeApp->>AuthServer: OAuth認可要求（Client Bとして） Victim->>AuthServer: 認可サーバーでログイン＆同意 AuthServer-->>FakeApp: 被害者のアクセストークン（Client B向け）を発行 Note over FakeApp,Attacker: 攻撃者が被害者のアクセストークンを入手！ Attacker->>TargetApp: 入手したトークンを送信してログインを試みる TargetApp->>AuthServer: トークンでユーザー情報を問い合わせ AuthServer-->>TargetApp: 被害者のユーザーIDを返却 Note over TargetApp: トークンの対象アプリ（Audience）を検証しないため
攻撃者が被害者アカウントに乗っ取り成功！

OAuth 2.0 は認可のためのプロトコルであるため、 「このトークンはどのクライアント向けに、誰がいつ認証された結果として発行されたか」 をクライアントが安全に検証する仕組みが備わっていません。

この問題を解決し、安全なソーシャルログインを実現するために標準化されたのが OpenID Connect（OIDC） です。

OpenID Connect（OIDC）とは？【OAuth 2.0 上に作られた「認証」プロトコル】

OpenID Connect（OIDC）は、OAuth 2.0 の認可フローをベースに、 「Identity（身元）の証明」と「プロファイル情報の安全な伝達」を行うための認証プロトコル です。

OpenID Foundation によって策定され、Google、Apple、Microsoft、LINE などの主要なソーシャルログインのデファクトスタンダードとなっています。

OIDC の最大の特徴：IDトークン（ID Token）

OIDC の核心となるのが、認証成功時にアクセストークンと一緒に発行される 「IDトークン（ID Token）」 です。

IDトークンは 運転免許証やパスポート に例えられます。免許証には「顔写真」「氏名」「生年月日」「有効期限」「発行元の公安委員会（電子署名）」が明記されており、提示された側（クライアントアプリ）がその場で本人であることを検証できます。

IDトークンは、 JWT（JSON Web Token） という規格でフォーマットが厳密に定められており、認可サーバーの秘密鍵による デジタル署名 が施されています。

IDトークン（JWT）の内部構造

IDトークンは、Base64URL でエンコードされた3つの部分（ヘッダー、ペイロード、署名）がドット（.）で連結された文字列です。

1
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmV4YW1wbGUuY29tIiwic3ViIjoiOTg3NjU0MzIxIiwiYXVkIjoibXktY2xpZW50LWlkIiwiZXhwIjoxNzg0MDY0MDAwLCJpYXQiOjE3ODQwNjA0MDAsImF1dGhfdGltZSI6MTc4NDA2MDM5MCwiZW1haWwiOiJ1c2VyQGV4YW1wbGUuY29tIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

デコードすると、以下のような JSON データが含まれています。

1
// 1. ヘッダー (Header)
2
{
3
  "alg": "RS256",
4
  "typ": "JWT"
5
}
6

7
// 2. ペイロード (Payload: クレーム情報)
8
{
9
  "iss": "https://accounts.example.com", // 発行者（IdP）のURL
10
  "sub": "987654321",                    // 一意のユーザー識別子（Subject）
11
  "aud": "my-client-id",                 // 想定された受信者（自社アプリのClient ID）
12
  "exp": 1784064000,                     // トークンの有効期限
13
  "iat": 1784060400,                     // トークンの発行日時
14
  "auth_time": 1784060390,               // ユーザーが実際にログイン（認証）した日時
15
  "email": "user@example.com"            // ユーザーのメールアドレス
16
}
17

18
// 3. 署名 (Signature)
19
// RSASHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secretOrPublicKey)

クライアントアプリは、IDトークンを受け取った際に以下の検証を行います。

署名の検証: 発行者の公開鍵（JWKS）を使って、改ざんされていないか確認する。
aud（Audience）の検証: 自社の client_id と一致しているか確認する（ トークン差し替え攻撃を完全に防ぐ ）。
iss（Issuer）の検証: 信頼できる認証局（Googleなど）から発行されたか確認する。
exp（Expiration）の検証: 有効期限が切れていないか確認する。

この仕組みにより、クライアントアプリは安全に「誰が今ログインしたのか」を判定できます。

OIDC が OAuth 2.0 に追加した3つの要素

OIDC は IDトークン以外にも、以下の重要な仕組みを仕様化しています。

openid スコープ: 認可リクエストの scope パラメータに openid を含めることで、OAuth サーバーに対して「OIDC 認証フローとして実行し、IDトークンを発行してほしい」と要求します。
UserInfo エンドポイント: アクセストークンを提示することで、名前やプロフィール画像、メールアドレスなどの詳細情報を取得できる標準化された RESTREST [レスト]Representational State Transfer。WebAPIの設計原則 API です。
Discovery 仕様（OpenID Connect Discovery）: https://example.com/.well-known/openid-configuration にアクセスするだけで、エンドポイントのURLURL [ユーアールエル]Uniform Resource Locator。Webページのアドレスやサポートしている暗号アルゴリズム、公開鍵一覧（JWKS）のURLを自動取得できる仕組みです。

OIDC / OAuth 2.0 の代表的な通信フロー【認可コードフロー + PKCE】

現代の Web アプリケーション（SPA含む）やモバイルアプリにおいて、最も安全とされ推奨されているのが 「認可コードフロー + PKCE（Proof Key for Code Exchange）」 です。

PKCE（ピクシー、RFC 7636）を併用することで、認可コード横取り攻撃を防ぎ、クライアントシークレットを安全に保持できない環境でも安全に認証・認可を行えます。

sequenceDiagram autonumber actor User as ユーザー（ブラウザ） participant Client as クライアント（自社Webアプリ） participant AuthServer as 認可サーバー / IdP（Google等） participant ResourceServer as リソースサーバー（API） User->>Client: 「Googleでログイン」をクリック Note over Client: code_verifier を生成し
code_challenge（ハッシュ値）を計算 Client->>AuthServer: 認可リクエスト（scope=openid profile, code_challenge等） AuthServer->>User: ログイン画面と同意画面を表示 User->>AuthServer: 認証情報（ID/パスワード）入力＆同意 AuthServer-->>Client: 認可コード（Authorization Code）をリダイレクトで返却 Client->>AuthServer: トークンリクエスト（認可コード + code_verifier） Note over AuthServer: code_verifier を検証し
認可コードの正当性を確認 AuthServer-->>Client: 【IDトークン】＋【アクセストークン】を発行 Note over Client: IDトークンの署名・aud・expを検証
→ ログイン成功（認証完了！） Client->>ResourceServer: アクセストークンを添えてAPI呼び出し ResourceServer-->>Client: リソースデータを返却（認可完了！）

このフローにおいて：

クライアントは IDトークン を使ってユーザーの本人確認（認証）を行います。
クライアントは アクセストークン を使ってリソースサーバーからデータ取得（認可）を行います。

OIDC を使うことで、「認証」と「認可」が美しく協調して動作することが分かります。

OAuth 2.0 と OIDC の使い分け基準

実務でどちらの技術を意識すべきか迷った際は、以下の基準で判断できます。

1. OpenID Connect（OIDC）を選ぶべきケース

自社サービスにソーシャルログイン機能を作りたい （「Googleアカウントでログイン」「Appleでサインイン」）
複数の社内システム間でシングルサインオン（SSO）を実現したい
ユーザーの基本プロフィール情報（ID、氏名、メールアドレス）を安全に取得したい

2. OAuth 2.0 を選ぶべきケース

自社サービスが他社のWeb APIを代理で操作したい （例: 自社アプリからユーザーのGitHubリポジトリ一覧を取得する、Googleドライブにファイルを保存する）
自社が公開するWeb APIにサードパーティアプリからの安全なアクセス制御を設けたい

現在提供されているソーシャルログイン機能（Google Identity、Sign in with Apple、LINEログイン v2.1など）は、 すべて OIDC に準拠 しています。

まとめ：OAuth 2.0 は認可、OIDC は認証

最後に、OAuth 2.0 と OpenID Connect（OIDC）の違いをまとめます。

OAuth 2.0 は「認可（権限の付与）」のための仕様: リソース（API）にアクセスするための「鍵（アクセストークン）」を発行する。
OIDC は「認証（本人確認）」のための仕様: OAuth 2.0 を拡張し、ユーザーの身元を証明する「免許証（IDトークン）」を発行する。
アクセストークンをログイン検証に使ってはいけない: トークン差し替え攻撃のリスクがあるため、ログイン機能には必ず OIDC の IDトークン（JWT）を用いる。
現代の推奨フローは「認可コードフロー + PKCE」: Webアプリやネイティブアプリにおいて、安全に認証・認可を完了できる標準ベストプラクティス。

それぞれの設計思想と得意分野を正しく理解し、安全な Web サービス・認証基盤の構築に役立ててください。

以上で本記事の解説を終わります。
よいITライフを！

この記事を書いた人

Z (ITナレッジライフ)

現役のITエンジニア。Linux、プログラミング、IT用語など、日々の業務で得た「痒いところに手が届く」技術情報を発信しています。

プロフィールと編集ポリシーを見る →

ITエンジニアにお勧めの本 ↗

お役立ちツール

ITニュース最新の技術ニュースをチェック

技術本書評/レビュープロ厳選のITエンジニア向け技術書

ポモドーロタイマー（Web）テレワークや勉強の集中に

ITエンジニアのコツコツ4択クイズこの記事の用語で腕試し

OAuth 2.0とOIDCの違いとは？認可と認証の仕組みを徹底比較

ITエンジニアにお勧めの本 ↗

OAuth 2.0 と OIDC の違いまとめ【比較表】

OAuth 2.0 とは？【認可（アクセス権限の委譲）のフレームワーク】

OAuth 2.0 が生まれた背景

OAuth 2.0 の4つの役割（Roles）

アクセストークンの役割

なぜ OAuth 2.0 単体で「ログイン（認証）」を作ってはいけないのか？【擬似認証の罠】

理由1：アクセストークンは「誰向け」に発行されたか検証できない

理由2：トークン差し替え攻撃（Token Substitution Attack）

OpenID Connect（OIDC）とは？【OAuth 2.0 上に作られた「認証」プロトコル】

OIDC の最大の特徴：IDトークン（ID Token）

IDトークン（JWT）の内部構造

OIDC が OAuth 2.0 に追加した3つの要素

OIDC / OAuth 2.0 の代表的な通信フロー【認可コードフロー + PKCE】

OAuth 2.0 と OIDC の使い分け基準

1. OpenID Connect（OIDC）を選ぶべきケース

2. OAuth 2.0 を選ぶべきケース

まとめ：OAuth 2.0 は認可、OIDC は認証

この記事の内容を4択クイズで腕試し！

Z (ITナレッジライフ)

ITエンジニアにお勧めの本 ↗

人気記事

VSCodeでソースコードのステップ数をカウント・集計する

VSCodeの「VS Code Counter」プラグインを使用すると、簡単にソースコードのステップ数をカウント・集計できます。サマリーの結果に加えて、言語ごと、ディレクトリごとの集計結果が出力(CSV,JSON,md等)されます。

ディレクトリ配下の権限・所有者を再帰的に変更する【Linux】

Linuxでディレクトリ配下のディレクトリ・ファイルの権限や所有者を再帰的に変更する場合は、chmodおよびchownコマンドに-Rオプションを指定します。

【WinMerge】プラグインでExcelファイルを比較する方法

WinMergeでPDFを比較する方法

WinMergeとApache PDFBoxプラグインを使って、PDFファイルの差分を確認する方法を解説します。プラグイン導入手順、実際の比較手順までを丁寧に紹介。PDFのテキスト比較を効率化したい方におすすめの記事です。

【Linux】viewコマンドの使い方

お役立ちツール

CORS（オリジン間リソース共有）とは？仕組みやエラー対処法を解説