OAuth 2.0・OIDCとは（全体像）
別のアプリに「自分のデータを一部だけ使わせたい」場面がある。たとえば、あるアプリにGoogleドライブの写真だけ読ませたい。このとき自分のパスワードをそのアプリに渡すのは危険だ。
そこで使うのがOAuth 2.0。パスワードを渡さずに、「写真フォルダだけ」のような限定的なアクセス権を発行するしくみ（＝認可）だ。
ただし、OAuthが扱うのは「何をしてよいか（認可）」であって、「誰か（認証）」ではない。「誰がログインしたか」を確かめるのは、OAuthの上に認証を乗せたOIDC（OpenID Connect）の役目。「Googleでログイン」は、このOIDCにあたる。
詳しく：登場人物とフローを押さえる
ここが心臓部。まずOAuthの4人の登場人物を整理する。
OAuthの登場人物
| 登場人物 | 役割 |
|---|---|
| Resource Owner | ユーザ本人（データの持ち主） |
| Client | アクセスしたいアプリ |
| Authorization Server | 許可を出す認可サーバ（Googleなど） |
| Resource Server | データを持つサーバ（API） |
そして、認可の進め方（フロー）にはいくつか種類がある。
おもなフローとOIDCとの違い
| 区分 | 内容 |
|---|---|
| Authorization Code | Webで使う標準のフロー |
| Authorization Code＋PKCE | SPAやモバイルで推奨（コード横取り対策） |
| Implicit | 旧方式。廃止推奨（PKCEを使う） |
| OAuth と OIDC | OAuth＝認可／OIDC＝認証（OAuthの上に乗せる） |
言葉を噛み砕いておく。
- 認可と認証のちがい … 認可（OAuth）＝何をしてよいか（写真フォルダへのアクセスを許す）、認証（OIDC）＝誰か（この人は確かに本人）。
- OIDC … OAuth 2.0の上に認証を乗せたしくみ。ID Tokenで「誰がログインしたか」を伝える。「Googleでログイン」はこれ。
- PKCE … 認可の途中で渡される「コード」を横取りされないようにする追加の対策。SPAやモバイルで推奨される。
わかりやすく言い換えると
つまり、OAuthはホテルの「限定ルームキー」を発行するしくみにたとえるとスッと入る。
あなたは、マスターキー（パスワード）をアプリに渡さない。代わりにフロント（認可サーバ）が、「この部屋だけ開く限定キー」をアプリに渡す。アプリはそのキーで許された範囲だけを使える。これが認可（OAuth）だ。
一方、「鍵を持っているのが誰か」をはっきりさせるのが認証（OIDC）。「Googleでログイン」は、限定キーに加えて「この人は田中さんです」という身分証明（ID Token）まで付けてくれる、というわけだ。
試験のツボ
🔴 一番出る：OAuthとOIDCの違い
①OAuth＝認可（パスワードを渡さず限定的なアクセス権を与える）
②OIDC＝認証（誰かを確かめる・OAuthの上に乗せる）
🔴 次に出る：フローの推奨と廃止
①SPAやモバイルはAuthorization Code＋PKCEが推奨
②Implicitは廃止推奨
🟡 押さえると安定：「Googleでログイン」はOIDC。登場人物はユーザ・アプリ・認可サーバ・APIの4人
よくある間違い
①「OAuthは認証のしくみだ」→ ✗ OAuthは認可（何をしてよいか）。認証（誰か）はOIDCが担う。
②「OAuthを使うとアプリに自分のパスワードを渡す」→ ✗ パスワードは渡さない。限定的なアクセス権だけを渡すのがOAuthの利点。
③「ImplicitフローはいまもSPAの標準」→ ✗ Implicitは廃止推奨。いまはAuthorization Code＋PKCEが推奨される。
試験での出題パターン
実際の問題でたしかめてみよう。
オリジナル問題1（OAuthとOIDCの違い）
OAuth 2.0とOIDCに関する次の記述のうち、正しいものはどれか。
- OAuthもOIDCもまったく同じもので、認可と認証のどちらも同じ言葉で表しているだけであるとされている
- OAuthは認証（誰か）を担い、OIDCは認可（何をしてよいか）を担うという、逆の役割になっているとされる
- OAuthは認可（何をしてよいか）を担い、認証（誰か）はOAuthの上に乗せたOIDCが担うという違いがある
- OAuthもOIDCも認証や認可とは無関係の、画像を圧縮するための形式の規格にすぎないとされているのが実情だ
解答は 3 である。
OAuthは認可（何をしてよいか）を担い、認証（誰か）は、OAuthの上に乗せたOIDCが担う。「Googleでログイン」はこのOIDCにあたる。
選択肢1は「まったく同じ」が誤り。選択肢2は認可と認証を逆にしている。選択肢4は「画像圧縮の形式」が誤りだ。
| 選択肢 | 判定 | 理由 |
|---|---|---|
| 1 | ✗ | 認可と認証で役割が違う |
| 2 | ✗ | OAuthが認可・OIDCが認証で逆 |
| 3 | ✓ | OAuth＝認可・OIDC＝認証で正しい |
| 4 | ✗ | 画像圧縮の形式ではない |
オリジナル問題2（OAuthの利点）
OAuthの利点に関する次の記述のうち、正しいものはどれか。
- OAuthはアプリへ自分のパスワードをそのまま渡す方式で、漏れたときの危険が大きいしくみとされているのだ
- OAuthはパスワードを渡さずに、写真フォルダだけといった限定的なアクセス権をアプリへ与えるしくみである
- OAuthはすべてのデータへの無制限のアクセスを一度に許す方式で、範囲を絞ることはできないとされている
- OAuthは通信の速度を上げるためだけのしくみで、アクセス権を与えることとは無関係であるとされているのだ
解答は 2 だ。
OAuthの利点は、パスワードを渡さずに、「写真フォルダだけ」のような限定的なアクセス権をアプリに与えられること。範囲を絞れるので安全だ。
選択肢1は「パスワードをそのまま渡す」が誤り。選択肢3は「無制限・範囲を絞れない」が誤り。選択肢4は「速度を上げるだけ」が誤りだ。
| 選択肢 | 判定 | 理由 |
|---|---|---|
| 1 | ✗ | パスワードは渡さない |
| 2 | ✓ | 限定的なアクセス権を与えるで正しい |
| 3 | ✗ | 範囲を絞って許可できる |
| 4 | ✗ | 速度を上げるしくみではない |
オリジナル問題3（フローの推奨）
OAuthのフローに関する次の記述のうち、正しいものはどれか。
- SPAやモバイルではいまもImplicitフローが唯一の標準で、ほかの方式はいっさい使ってはいけないとされているのだ
- OAuthには登場人物がユーザ1人しかおらず、アプリや認可サーバといった役割は存在しないとされているのだ
- OAuthのフローはどれも安全性がまったく同じで、新しいものへ移る必要はいっさいないとされているのが実情だ
- SPAやモバイルはAuthorization Code＋PKCEが推奨され、Implicitは廃止推奨だとされている
解答は 4 だ。
SPAやモバイルでは、コードの横取りを防ぐAuthorization Code＋PKCEが推奨される。古いImplicitは廃止推奨だ。
選択肢1は「Implicitが唯一の標準」が誤り。選択肢2は「登場人物がユーザ1人だけ」が誤りで、4人いる。選択肢3は「どれも同じ・移る必要なし」が誤りだ。
| 選択肢 | 判定 | 理由 |
|---|---|---|
| 1 | ✗ | Implicitは廃止推奨 |
| 2 | ✗ | 登場人物は4人いる |
| 3 | ✗ | フローで安全性が違う |
| 4 | ✓ | PKCE推奨・Implicit廃止推奨で正しい |
まとめ
押さえどころ
- 🔴 OAuth 2.0 ＝ パスワードを渡さず、限定的なアクセス権を与える「認可」のしくみ。
- 🔴 OIDC ＝ OAuthの上に乗せた「認証」（誰か）。「Googleでログイン」はOIDC。OAuth＝認可・OIDC＝認証。
- 🟡 SPAやモバイルはAuthorization Code＋PKCEが推奨。Implicitは廃止推奨。登場人物はユーザ・アプリ・認可サーバ・APIの4人。
次に学ぶ
- 認証要素・MFA（多要素認証） ── OIDCでの本人確認を強くする、認証要素のしくみ。
- パスキー・WebAuthn・FIDO2 ── パスワードレスでログインする、現代の認証のしくみ。
- ゼロトラストNW・BeyondCorp ── 認可と認証を前提にする、現代のセキュリティの考え方。
執筆: SikakuQuest編集部