開発現場で頻繁に混同される「OAuth 2.0」と「OpenID Connect (OIDC)」。両者の決定的な違い（認可 vs 認証）と、正しい使い分けの基準を解説します。
OAuth 2.0 は「認可」、OIDC は「認証」
現代のWebアプリケーション開発において必須の知識である「OAuth 2.0」と「OpenID Connect (OIDC)」ですが、この2つは頻繁に混同されます。その最大の理由は「OIDCがOAuth 2.0を拡張して作られている」ため、見た目や通信のフローが非常に似ているからです。
しかし、両者の目的は根本的に異なります。
- OAuth 2.0: 何かをする権限を与える**「認可（Authorization）」**のプロトコル。
- OIDC (OpenID Connect): ユーザーが誰であるかを確認する**「認証（Authentication）」**のプロトコル。
OAuth 2.0 の正しい使い方（APIアクセス権の委譲）
OAuth 2.0は、アプリがユーザーの代わりに別のサービス（API）にアクセスするための権限を安全に渡す仕組みです。 例えば、「家計簿アプリ」が「銀行のAPI」から取引履歴を取得する場合を考えます。家計簿アプリに銀行のパスワードを直接教えるのは非常に危険です。そこでOAuth 2.0を使うと、銀行は家計簿アプリに対して「取引履歴を読むことだけができる専用の鍵（アクセストークン）」を発行します。これにより、パスワードを渡さずに安全にデータ連携ができます。
OAuth 2.0 を「ログイン」に使ってはいけない理由
過去には、このOAuth 2.0のアクセストークンを利用して「この鍵を持っていればログイン済みとみなそう」とする、いわゆる「疑似認証」が横行しました。 しかし、アクセストークンには「誰がログインしたか」や「どのアプリ向けに発行されたか」という情報が含まれていません。そのため、悪意のあるアプリが取得したアクセストークンを使い回して、別のアプリに不正ログインする（Token Replacement Attackなど）脆弱性の温床となっていました。
OIDC の正しい使い方（ログイン・SSO）
この問題を解決するために作られたのがOIDCです。OIDCでは、アクセストークンに加えて**「IDトークン」**と呼ばれるJWT（JSON Web Token）形式のデジタル身分証が発行されます。
IDトークンには、「認証されたユーザーのID」「発行元（Googleなど）」「宛先となるアプリ」が明記され、さらに改ざん防止のデジタル署名が施されています。 アプリ側は、このIDトークンを検証することで、安全かつ確実に「誰がログインしてきたか」を把握できます。
まとめ：開発時の使い分け基準
- 「〇〇でログイン」のようなシングルサインオン機能を実装したい場合は、必ずOIDCを利用し、IDトークンを検証してください。
- 自社のアプリからGoogle Calendar APIやTwitter APIなどの外部リソースを操作したい場合は、OAuth 2.0を利用し、アクセストークンを取得してください。
この記事を書いた人：19kl42 編集部
デジタルアイデンティティ、eKYC、プライバシー保護などの複雑な仕組みを「共通言語」へと翻訳して発信しています。誰もが「デジタルな自分」を正しく扱い、信頼をデザインできる社会を目指しています。