はじめに
情報処理安全確保支援士の勉強をしていく中でよく出てくるOAuth2.0。
SMALとの違いも調べた内容はわかりますが、OAuth2.0の中にも認証方式で様々な種類があることを調べていて理解しました。
そのため、一度本腰入れてまとめることで理解を深めようと思います。
まず、OAuth2.0とはなにか簡単に
一言でいうと 「認可（authorization）フレームワーク」
ここではOAuth2.0とはなにかは詳しくは触れません。
その中でも 「どのようにユーザが認証され、トークンが発行されるか」 の違いによっていくつかの「認証方式（＝グラントタイプ / フロー）」が存在します。
🔷 OAuth 2.0 の代表的な認証方式（グラントタイプ）
ざっと紹介すると以下の5点がOAuth2.0の認証方式になります。ただ、基本的によく出てくるのは①と②かなと。
それ以外は興味ある人以外読み飛ばしてもよいです。
| 1 | 2 |
|---|---|
| 認証方式（グラントタイプ） | 用途と特徴 |
| ① 認可コードグラント（Authorization Code Grant） | 🔹Webアプリ向け。ユーザの認可とバックエンドでのトークン取得を分離。最も安全。 |
| ② PKCE付き認可コードグラント | 🔹ネイティブアプリ／スマホアプリ向け。認可コードグラントのセキュリティ強化版。🔹code_challenge / code_verifierを使ってトークンなりすましを防ぐ |
| ③ インプリシットグラント（Implicit Grant） | 🔸古いSPA（JSアプリ）向け。アクセストークンをURLに埋めて直接取得。⚠️ セキュリティ上問題があり、現在は非推奨（RFCで廃止予定） |
| ④ リソースオーナーパスワードクレデンシャル（ROPC） | 🔸信頼されたアプリ専用。ユーザのID・パスワードをアプリが直接扱う。⚠️ ユーザの認証情報を直接扱うため、基本非推奨 |
| ⑤ クライアントクレデンシャルグラント（Client Credentials Grant） | 🔹**機械 to 機械（M2M）**でのアクセス用。ユーザは登場しない。🔹サーバ or バッチ処理がAPIアクセスする場合などに使う |
✅ 各方式の適用ケースと安全性比較
| フロー | 対象 | 安全性 | 備考 |
|---|---|---|---|
| 認可コード + PKCE | スマホ／SPA／Web | ◎ | 現代標準、IDトークンとの併用も可 |
| 認可コード（PKCEなし） | 旧Webアプリ | ◯ | クライアントシークレット必須 |
| クライアントクレデンシャル | サーバAPI（非ユーザ） | ◎ | ID連携なし、アプリ認証のみ |
| ROPC | 信頼された自社アプリ限定 | △ | 認証情報を直接扱うリスク |
| インプリシット | 旧SPA（JavaScriptアプリ） | × | 廃止推奨、現在は使わない |
✅ 補足：OAuthとOpenID Connectの違い
| フレームワーク | 主な目的 | 取得できるもの |
|---|---|---|
| OAuth 2.0 | 認可 | アクセストークン（API通行証） |
| OpenID Connect (OIDC) | 認証 | IDトークン（ユーザ情報付きJWT） |
➡ 「OAuthは認可、OIDCは認証」という関係です。
＊備忘として記載しました。
それぞれの認証方式をシーケンス図で
ここから本題の図解に入ります。
① 認可コードグラント（Authorization Code Grant）
✅ このフローで押さえるべきポイント：
ステップ 内容
認可リクエスト（GET） /authorize にリダイレクト、同意画面
認可コードの受け取り クライアントが code を受け取る
トークン要求（POST） code を使ってトークン取得
アクセストークンでAPI呼び出し 実際のデータ取得
② PKCE付き認可コードグラント
✅ 補足：PKCEで使われる要素
要素 役割
code_verifier クライアント側で生成されるランダムな秘密値
code_challenge code_verifier をハッシュ（例：S256）してサーバに渡す
code_challenge_method ハッシュの方法（通常は S256）
認可サーバ トークン要求時に code_verifier を照合して正当性を確認
③ インプリシットグラント（Implicit Grant）
📌 特徴：認可コードを介さず、ブラウザURL経由で直接トークンが返るため、XSSなどに非常に弱い。
📌 現在は非推奨・使用禁止（RFC 8252, 8816）
④ リソースオーナーパスワードクレデンシャル（ROPC）
📌 特徴：クライアントがユーザのパスワードを直接扱うため、セキュリティ上のリスクが高い。
📌 基本的に使用すべきでない。社内システムなど一部用途限定で利用。
⑤ クライアントクレデンシャルグラント（Client Credentials Grant）
📌 特徴：ユーザを介さない機械同士（M2M）のアクセス向け。
📌 バックエンドAPIの自動実行・CI/CDなどで活躍。
最後に
①～⑤を紹介しましたが、基本的によく目にするのは以下だと思います。
- ① 認可コードグラント（Authorization Code Grant）
- ② PKCE付き認可コードグラント
上述の情報がOAuth2.0への理解が深まえれば幸いです。