OAuth=認可、OIDC=認証だけじゃ分からない！違いを5分で完全理解

December 6, 2025March 29, 2026

「OAuthとOIDC、どっちもログインに使うんでしょ？」と思っていませんか？実は、OAuthは認可のプロトコル、OIDCは認証のプロトコルです。しかし、この一言だけでは「結局何が違うの？」という疑問は解消されません。

この記事では、OAuthとOIDCの違いを実例を使って5分で完全理解できるように解説します。「なぜOAuthを認証に使ってはいけないのか」「OIDCはOAuthの上に構築されているとはどういうことか」まで、本質的な理解を目指しましょう。

「どっちもログインに使うんでしょ？」よくある誤解

OAuthとOIDCが混同される理由

OAuthとOIDCが混同されやすい理由は、どちらも「Googleでログイン」のようなソーシャルログインで使われるからです。実際、多くのサービスでは両者を組み合わせて実装しています。

しかし、目的がまったく異なります：

OAuth：第三者に「リソースへのアクセス権」を与える（認可）
OIDC：「このユーザーが誰であるか」を確認する（認証）

なぜ違いが分かりにくいのか

違いが分かりにくい最大の理由は、OIDCがOAuthの上に構築された「追加レイヤー」だからです。技術的には密接に関連しているため、境界線が曖昧に見えてしまいます。

しかし、両者の目的と仕組みを理解すれば、実装時にどちらを使うべきか明確に判断できるようになります。

OAuth（認可）とは？写真印刷サービスで理解する

OAuthの目的：第三者にリソースへのアクセス権を与える

OAuthは、リソースの所有者が、リソースへのアクセス権を第三者に与える仕組みです。RFC 6749では以下のように定義されています：

「OAuth 2.0は、サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである」

アクセストークンの役割

OAuthではアクセストークンという「鍵」を使ってリソースにアクセスします。アクセストークンは以下の特性を持っています：

持っていれば使える：鍵の利用者を検証しない（一般的な場合）
漏洩のリスク：一度漏洩すると誰でもリソースにアクセスできてしまう
有効期限は短く：漏洩に備え、鍵の有効期限を短く保つことが推奨
スコープで範囲指定：「どのリソースに」「どのような操作を」許可するかを指定

具体例：Google Photosの写真を印刷サービスに渡す

写真印刷サービスを例に考えてみましょう。あなたがGoogle Photosに保存している写真を、別の印刷サービスで印刷したい場合：

❌ 従来の方法（OAuthなし）

印刷サービスにGoogleのパスワードを教える
印刷サービスが自分の代わりに写真にアクセス
問題：写真以外（メール、連絡先など）にもアクセスされる危険性

✅ OAuthを使った方法

「写真を読み取る権限のみ」を持つアクセストークンを発行
印刷サービスにアクセストークンを渡す
印刷サービスは写真のみにアクセス可能
パスワードを教える必要がない

このように、OAuthは「何ができるか」を限定的に許可する仕組みです。

OIDC（認証）とは？Googleログインで理解する

OIDCの目的：ユーザーの本人確認とプロフィール取得

OIDC（OpenID Connect）は、ユーザーの本人確認（認証）とプロフィール情報の取得を行うための仕組みです。OpenID Connect Core 1.0では以下のように定義されています：

「OpenID Connect 1.0は、OAuth 2.0プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである」

IDトークンの役割

OIDCではIDトークンという「プロフィール証明書」を使います。IDトークンには以下の情報が含まれます：

ユーザーID：一意な識別子
発行者情報：誰がこのトークンを発行したか
有効期限：いつまで有効か
プロフィール情報：名前、メールアドレスなど（オプション）

具体例：ZennにGoogleアカウントでログイン

Zennのようなサービスに「Googleでログイン」する場合を考えてみましょう：

「Googleでログイン」ボタンをクリック
Googleのログイン画面が表示される
Googleアカウントでログイン
Zennに戻り、ログインが完了

このとき内部では：

ZennはGoogleからIDトークンを受け取る
IDトークンには「このユーザーは確かにGoogleアカウントを持っており、このようなプロフィール情報を持っている」という情報が含まれる
Zennはこの情報を信頼してログインを許可

このように、OIDCは「誰であるか」を確認する仕組みです。

認可と認証の決定的な違いを整理

認可：「何ができるか」を許可

認可（Authorization）は、あるアクションを実行する権限があるかを判断します。

例：印刷サービスに「写真を読み取る権限」を与える
焦点：何ができるか（権限）
使うもの：アクセストークン

認証：「誰であるか」を確認

認証（Authentication）は、ユーザーが本当にその人物であるかを確認します。

例：このユーザーが確かに山田太郎であると確認
焦点：誰であるか（身元）
使うもの：IDトークン

比較表で一目瞭然

項目	OAuth（認可）	OIDC（認証）
目的	リソースに対する認可	ユーザーの本人確認
主な用途	第三者サービスにリソースへのアクセス権を与える	第三者サービスにログインする
取得するもの	アクセストークン	IDトークン（+ アクセストークン）
答える質問	「何ができるか？」	「誰であるか？」
具体例	写真印刷サービスに写真へのアクセス権を付与	Googleアカウントでログイン

なぜOAuthを認証に使ってはいけないのか？

OAuthは認証用に設計されていない

OAuthはあくまで認可のプロトコルであり、認証の仕組みとしては設計されていません。OAuthを認証に転用すると、以下のような問題が発生します：

アクセストークンは「誰か」を証明しない：アクセストークンは「何ができるか」を示すだけで、「誰が」そのトークンを持っているかは保証しない
トークンの漏洩リスク：アクセストークンが漏洩すると、攻撃者がそのトークンを使ってリソースにアクセスできてしまう
なりすましの危険性：アクセストークンを盗んだ第三者が、正当なユーザーとしてログインできてしまう可能性

セキュリティリスクの具体例

OAuthを認証に誤用した場合の具体的なリスク：

シナリオ：悪意のあるアプリが正規のアクセストークンを取得

攻撃者が正規のOAuthフローで自分のアクセストークンを取得
攻撃者がこのアクセストークンを被害者のブラウザに注入
被害者のサービスがアクセストークンの存在だけで「ログイン成功」と判断
被害者は攻撃者のアカウントでログインしてしまう

このような攻撃を防ぐため、認証にはOIDCを使う必要があります。

「餅は餅屋」の原則

プロトコルは目的に応じて使い分けるべきです：

認可が必要 → OAuth を使う
認証が必要 → OIDC を使う
両方必要 → OIDC を使う（OIDCはOAuthを含むため）

「餅は餅屋」。認証には認証専用のプロトコルであるOIDCを使いましょう。

OIDCはOAuthの「追加レイヤー」という技術的な関係

OIDCはOAuthの上に構築されている

OIDCは技術的にはOAuthの上に構築された追加レイヤーです。OpenID Connect Core 1.0の定義でも明確に示されています：

「OpenID Connect 1.0は、OAuth 2.0プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである」

つまり：

OIDCはOAuthの仕組みをそのまま利用している
OAuthの認可フローに「認証」の機能を追加している
IDトークンという新しい概念を導入している

/userinfoエンドポイントの例

OIDCとOAuthの関係を示す具体例として、OIDCの/userinfoエンドポイントがあります：

/userinfoエンドポイントはアクセストークンを使ってプロフィール情報を取得する
これはOAuthの認可の仕組みを利用している
つまり、OIDCはOAuthの上に構築されているため、OAuthの機能も活用できる

また、OIDC側で発祥した仕様（PKCE、stateパラメータなど）がOAuth側に逆輸入されることもあり、両者は相互に影響し合っています。

なぜOAuth理解がOIDC理解の前提なのか

OIDCを正しく理解・実装するには、まずOAuthの理解が不可欠です：

認可コードフロー：OIDCもOAuthと同じ認可コードフローを使う
アクセストークン：OIDCでもアクセストークンを使う場面がある
セキュリティ機構：PKCE、stateパラメータなどはOAuthとOIDC共通
スコープ：OIDCではopenidスコープを指定してOAuthフローを開始

OAuthの基礎がしっかりしていれば、OIDCは「認証機能が追加されたOAuth」として理解できます。

実装時の使い分け判断基準

リソースアクセスが目的 → OAuth

以下の場合はOAuthを使います：

第三者サービスに自分のデータへのアクセス権を与える
API連携でリソースにアクセスする
特定のスコープに限定したアクセス権を付与する

実装例：

Google Photosの写真を印刷サービスに共有
Slackボットが自分のメッセージを投稿
カレンダーアプリがGoogleカレンダーの予定を読み取る

ログインが目的 → OIDC

以下の場合はOIDCを使います：

ソーシャルログイン（Googleでログイン、GitHubでログインなど）
ユーザーの本人確認が必要
ユーザーのプロフィール情報を取得したい

実装例：

ZennにGoogleアカウントでログイン
GitHubアカウントで開発者サービスにログイン
社内システムにシングルサインオン（SSO）でログイン

実装例の違い

OAuthとOIDCの実装の違いを認可リクエストで比較してみましょう：

OAuth（認可）の場合：

https://accounts.google.com/o/oauth2/v2/auth
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.com/callback
  &scope=https://www.googleapis.com/auth/photoslibrary.readonly

OIDC（認証）の場合：

https://accounts.google.com/o/oauth2/v2/auth
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.com/callback
  &scope=openid profile email

違いはscopeパラメータです：