「OAuth認証」と呼んでいませんか？
「うちのサービス、OAuth認証でGoogleログインできるようにしました」。この説明、実は技術的に正確ではありません。OAuthは「認証」ではなく「認可」のフレームワークだからです。
「認証と認可って違うの？」「OAuthで認証しちゃダメなの？」「じゃあGoogleログインは何なの？」 ― こうした疑問を一つずつ整理していきます。
認証と認可の違い ― 30秒で理解する
まず、この2つの違いを日常の例で考えましょう。
【認証（Authentication）】= 「あなたは誰？」
ホテルのフロントでパスポートを見せて、本人確認する
→ 身元を証明すること
【認可（Authorization）】= 「あなたは何ができる？」
ホテルのカードキーで、自分の部屋だけ入れる（他の部屋は入れない）
→ 権限を与えること| 項目 | 認証（Authentication） | 認可（Authorization） |
|---|---|---|
| 問い | あなたは誰ですか？ | あなたは何をしていいですか？ |
| 目的 | 本人確認 | アクセス権限の付与 |
| 日常の例 | パスポート、社員証 | 部屋のカードキー、入館証 |
| 技術の例 | ID/パスワード、生体認証 | OAuth、IAMポリシー |
認証は「誰か」を確認すること。認可は「何ができるか」を決めること。この2つは別の概念です。
OAuthは「認可」のフレームワーク
OAuth 2.0は、「あるサービスが持っているリソースへのアクセス権を、別のサービスに委譲する」ための仕組みです。
具体例で見てみましょう。
【OAuthの典型的な流れ】
1. あなたが写真編集アプリを使いたい
2. 写真編集アプリが「Googleフォトの写真を読み取っていいですか？」と聞く
3. あなたがGoogleの画面で「許可」を押す
4. 写真編集アプリがGoogleフォトの写真にアクセスできるようになる
→ これは「認可」。写真編集アプリに「Googleフォトを読む権限」を与えた
→ 写真編集アプリは「あなたが誰か」を知る必要はないOAuthが発行するのはアクセストークンです。このトークンは「Googleフォトの写真を読み取れる」という権限情報を持っていますが、「このトークンの持ち主が誰か」という情報は含んでいません。
ここがポイントです。アクセストークンは「鍵」のようなもの。鍵を持っていればドアは開くけれど、鍵は「誰が持ち主か」を教えてくれない。だからアクセストークンが盗まれたら、盗んだ人もドアを開けられてしまう。
OIDCは「認証 + 認可」のフレームワーク
では「Googleでログイン」は何を使っているのか。答えはOIDC（OpenID Connect）です。
OIDCはOAuthを拡張して「認証」の機能を追加した仕組みです。OAuthの認可フローに加えて、IDトークンを発行します。
| 項目 | OAuth 2.0 | OIDC（OpenID Connect） |
|---|---|---|
| 目的 | 認可（リソースへのアクセス委譲） | 認証 + 認可 |
| 発行するトークン | アクセストークン | アクセストークン + IDトークン |
| ユーザー情報 | 含まない | IDトークンに含まれる（メール、名前等） |
| 「誰か」が分かるか | ❌ | ✅ |
| 典型的な用途 | API連携、サードパーティアクセス | Googleでログイン、SSOなど |
IDトークンはJWT（JSON Web Token）形式で、「このトークンを発行したのはGoogle」「対象ユーザーのメールアドレスはxxx@gmail.com」といった情報が署名付きで含まれています。署名を検証すれば、改ざんされていないことが確認できる。
つまり、「Googleでログイン」を正しく実装するなら、OAuthではなくOIDCを使うべき。OAuthのアクセストークンだけでログインを実装すると、セキュリティ上の問題が生じます。
なぜ「OAuth認証」が危ないのか
OAuthのアクセストークンだけで「認証」を実装した場合、以下のリスクがあります。
トークン置換攻撃
アクセストークンには「誰に対して発行されたか」「どのアプリに対して発行されたか」の情報がありません。悪意あるアプリAで取得したアクセストークンを、別のアプリBのログインに使い回すことが可能になります。
【トークン置換攻撃のイメージ】
1. ユーザーが悪意あるアプリAにOAuthでログイン
2. アプリAがユーザーのアクセストークンを入手
3. アプリAがそのトークンを使って、アプリBにユーザーとしてログイン
4. アプリBはトークンの「持ち主」を確認できないので、そのまま通してしまうOIDCのIDトークンにはaudience（対象アプリ）やissuer（発行者）が含まれているため、「このトークンはこのアプリ向けに発行されたものか？」を検証でき、この攻撃を防げます。
結局どう使い分ける？
| やりたいこと | 使うべきもの |
|---|---|
| 「Googleでログイン」を実装したい | OIDC |
| SSO（シングルサインオン）を導入したい | OIDC |
| 外部サービスのAPI（Google Drive等）にアクセスしたい | OAuth 2.0 |
| 自分のAPIへのアクセス制御をしたい | OAuth 2.0 |
| ログイン + API連携の両方 | OIDC（OAuthの認可機能も含む） |
迷ったら「ユーザーが誰かを確認する必要があるならOIDC、リソースへのアクセス権だけが必要ならOAuth」と覚えておけばOKです。
認証・セキュリティの理解を深める関連記事
- リリース前に必ず確認！バイブコーディング＆非エンジニア向けWebアプリ安全チェックリスト – 認証まわりのセキュリティチェックを含むリリース前確認
- 「それ、上げちゃダメ！」GitHub管理で絶対守るべきセキュリティルールと対処法 – OAuthトークンやAPIキーの管理で押さえるべき基本
- 「全部POSTでよくない？」がモヤる人へ｜HTTPメソッド使い分けの正論と現場のリアル – OAuth認可で保護するAPIの設計判断
- Claude Codeとは？AI搭載のコーディングアシスタントを徹底解説 – OIDC実装のコード生成をAIに相談する活用法
まとめ：認証ならOIDC、認可ならOAuth
- 認証 = 「あなたは誰？」、認可 = 「あなたは何ができる？」。別の概念
- OAuthは認可のフレームワーク。アクセストークンは「権限」を持つが「誰か」は分からない
- OIDCはOAuthを拡張して認証を追加。IDトークンで「誰か」を安全に確認できる
- OAuthだけでログインを実装するとトークン置換攻撃のリスクがある
- 「Googleでログイン」はOIDC。「OAuth認証」という表現は技術的に不正確
「OAuth認証」と呼んでしまうこと自体は、開発者の間でも非常によくある混同です。ただ、この違いを理解していないと、認証の実装で本質的なセキュリティホールを作ってしまう可能性がある。認証が必要ならOIDC、認可だけならOAuth。この一行を覚えておくだけで、設計の判断がクリアになります。
