Zenn
🔐

雰囲気で使っていませんか？OAuth2.0の基礎をざっくり整理してみた

に公開
API
Security
OAuth 2
認可
tech

雰囲気で使っていませんか？OAuth2.0の基礎をざっくり整理してみた

〜スコープ、グラントタイプ、リフレッシュトークンまでまとめて解説〜

最近のWebサービスやAPI連携でよく登場する OAuth2.0。
「なんとなく使ってるけど実はよく分かっていない…」という方も多いのでは？

この記事では、OAuth2.0の基本的なフロー・セキュリティの考え方をわかりやすく整理します。

💡 この記事は、OAuth2.0を学び直すために読んだ
📘 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本
を参考にしながら、自分用のインプットまとめとして書いたものです。
書籍もとても分かりやすいので、さらに深く知りたい方にはおすすめです！

✅ OAuth2.0の登場人物と役割

  • リソースオーナー（ユーザー）
    データの持ち主。例：Google Photoの写真所有者。

  • クライアント（アプリ）
    データにアクセスしたいアプリ。例：画像編集アプリなど。

  • リソースサーバー（API）
    実際のデータを保持しているAPI。アクセストークンがないとアクセスできない。

  • 認可サーバー
    クライアントが「このユーザーのデータにアクセスしてもいいですか？」と確認する相手。
    アクセストークンもここから発行される。

✅ アクセストークンとスコープの役割

  • アクセストークン
    リソースサーバーに「このクライアントは許可されています」と伝える通行証。

  • スコープ
    そのトークンで「何ができるか」の範囲を定義する。たとえば：

スコープ名 権限
photoslibrary.readonly 写真を読み取り
photoslibrary.appendonly 写真の追加
photoslibrary.sharing 写真の共有

→ 最小限の権限で、安全なアクセスを実現するために欠かせない。

✅ OAuth2.0のグラントタイプ（付与方法）

1. 認可コードグラント（Authorization Code Grant）

最も一般的な方式。セキュリティが高く、Webアプリやモバイルアプリ（+PKCE）向け。

2. インプリシットグラント（Implicit Grant）

クライアントが直接アクセストークンを受け取る方式。SPA向けだったが、
現在はセキュリティ上の理由から非推奨。

  • トークンがURLに含まれて届く（漏洩リスク）
  • リフレッシュトークンが使えない

3. クライアントクレデンシャルグラント（Client Credentials Grant）

ユーザーを介さず、クライアント自身がアクセスする方式。サーバー間通信やバッチ処理向け。

4. リソースオーナーパスワードクレデンシャルグラント（ROPC）

ユーザーのIDとパスワードをクライアントに直接渡す方式。
信頼されたアプリ以外では非推奨。

✅ リフレッシュトークンとは？

  • アクセストークンは短命（例：1時間）
  • ログインし直さずに継続アクセスするために使う
  • 長期間使えるが、漏洩リスクが高い

→ セキュリティが強化された設計でのみ利用されるべき。

グラントタイプの使い分け（チャート）

┌──────────────────────────────┐
│ クライアントは信頼できるか？     │
└────┬─────────────────────┘
     │Yes
     ▼
  ┌────────────────────────────┐
  │ サーバー間通信か？            │
  └────┬────────────────────┘
       │Yes                │No
       ▼                    ▼
  Client Credentials   Authorization Code（+PKCE）
                           │
                           ▼
                  リフレッシュトークン利用可

✅ PKCEとは？なぜ必要？

モバイルアプリやJavaScriptアプリのように、クライアントシークレットを安全に保てない環境では、
認可コードが「横取り」されるリスクがあります。

PKCE（Proof Key for Code Exchange）は、それを防ぐ仕組み。

  • 認可リクエスト時に code_challenge を送信
  • トークン取得時に code_verifier を送信
  • 認可サーバーが照合して、正当なクライアントか検証

→ 認可コードが盗まれても、トークン発行を防げる

✅ まとめ

OAuth2.0の仕組みを理解すると、APIとのやり取りの「なぜこうなってるのか」が見えてきます。

  • なぜトークンが必要なのか？
  • なぜPKCEを使うのか？
  • どのグラントタイプを選ぶべきか？

これらを理解することで、セキュリティを意識した実装ができるようになります。

📘 もっと詳しく知りたい方へ

OAuth2.0の基礎だけでなく、図解やシーケンス図で学びたい方にはこちらの書籍がとてもおすすめです👇

📘 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本

  • 図解やフローが丁寧で、理解の助けになる
  • 実装やPKCEなど、実務レベルで必要な知識もフォロー
  • 雰囲気から卒業したい人にぴったりな一冊

Discussion