採用に向く条件
選ぶ理由
- パスワードを共有せず権限委譲
- スコープで権限を細かく絞れる
- 業界標準で連携先が豊富
製品プロフィール
OAuth 2.0
認可フレームワーク
パスワードを渡さずに、サードパーティへ「ここまでアクセスしてよい」という権限を委譲する認可の標準。「〇〇でログイン」や API 連携の土台。
3つの要点
TL;DR- パスワードを渡さず権限を委譲する認可の標準。
- スコープで「どこまで許すか」を細かく絞れる。
- 本人確認も要るなら OIDC を上に重ねる。
基本情報
仕様と立ち位置
- 製品・技術の概要OAuth 2.0パスワードを渡さずに、サードパーティへ「ここまでアクセスしてよい」という権限を委譲する認可の標準。「〇〇でログイン」や API 連携の土台。
- 種別
- 認可フレームワーク
- 目的
- 認可
（アクセス委譲） - トークン/形式
- アクセストークン
- 最大の強み
- パスワードを共有せず権限委譲スコープで権限を細かく絞れる
- 代表的な用途
- API へのアクセス委譲「〇〇でログイン」の基盤 / サードパーティ連携
選定ガイド
選定ポイント
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
事前に確認する条件
考慮すべき点
- あくまで認可で、本人確認(認証)は別（→ OIDC）
- フローが複数あり実装を誤ると危険
- リダイレクト/トークン管理に注意
詳しい解説
もっと詳しく
どんな仕組みか
OAuth 2.0 は、パスワードを相手に渡さずに「ここまでアクセスしてよい」という権限だけを第三者へ委譲するための標準仕様（RFC 6749）です。鍵となるのは「アクセス委譲（認可）」であって、本人確認そのものではありません。
たとえば、あるアプリに「Google ドライブの特定ファイルだけ読ませたい」とき、Google のパスワードをアプリに教える代わりに、限定された権限を持つアクセストークンを発行して渡します。
横にスクロール
登場人物と用語
OAuth 2.0 は 4 つの役割で構成されます。
- リソースオーナー: 本人（データの持ち主）。
- クライアント: アクセスしたいアプリ。
- 認可サーバー: 同意を受けてトークンを発行する。
- リソースサーバー: トークンを検証して API を提供する。
権限は スコープ（scope） で「読み取りだけ」「特定の範囲だけ」と絞り込み、発行された アクセストークンには有効期限があり、切れたら リフレッシュトークンで再取得します。
どう動くのか（グラントタイプ）
権限取得の流れ（グラントタイプ）は用途別に複数あります。
| フロー | 用途 | 特徴 |
|---|---|---|
| 認可コード + PKCE | Web/モバイル/SPA(現行の標準) | ブラウザ経由で同意→コードをトークンに交換。PKCE で横取り対策 |
| クライアントクレデンシャル | サーバー間(ユーザー不在) | アプリ自身の資格でトークン取得 |
| デバイスコード | TV・CLI など入力が貧弱な端末 | 別端末でコードを入力して認可 |
| インプリシット/パスワード | 非推奨 | 旧式。現在は使わない方向 |
現在は、SPA やモバイルでも 認可コードフロー＋PKCE を使うのが推奨です。
1. クライアント → 認可サーバー: 認可リクエスト(scope, PKCE)
2. ユーザーが同意 → 認可コードを受領
3. クライアント → 認可サーバー: コードをアクセストークンに交換
4. クライアント → リソースサーバー: トークンを付けて API 呼び出し
他の方式との違い（認可 ≠ 認証）
OAuth 2.0 が扱うのはあくまで「何にアクセスしてよいか」という認可です。「誰がログインしたのか」という本人確認（認証）は対象外で、その役割は上に乗せる OpenID Connect が担います。
「○○でログイン」と書かれていても、ログイン（認証）部分は OIDC、外部サービスへの API 連携部分は OAuth 2.0、と整理すると混乱しにくくなります。
使いどころ・注意点
SaaS 同士の連携や、外部アプリに自社 API を使わせる場面の土台として広く使われます。
認可を認証に流用しない
OAuth 2.0 を「ログインの仕組み」と誤解したまま認証に流用すると、本人確認の保証が不十分になります（トークンを持っている＝本人とは限らない）。認証が必要なら OIDC を併用します。実装では、スコープを最小限に絞り、リダイレクト URI の完全一致検証、state による CSRF 対策、PKCE の使用を徹底し、トークンは安全に保管します。
総じて OAuth 2.0 は、パスワードを共有せずに限定権限を委譲する現代の API 連携の土台で、PKCE と最小スコープを前提に設計することが安全運用の鍵です。
実装・運用の視点
OAuth 2.0を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
API へのアクセス委譲
比較で見る軸
種別: 認可フレームワーク / 目的: 認可（アクセス委譲） / トークン/形式: アクセストークン
導入後に効く点
スコープで権限を細かく絞れる
先に潰すリスク
あくまで認可で、本人確認(認証)は別（→ OIDC）
数字・仕様の読み方
- 種別
- 認可フレームワーク
- 目的
- 認可（アクセス委譲）
- トークン/形式
- アクセストークン
判断チェックリスト
- 自社の用途が「API へのアクセス委譲 / 「〇〇でログイン」の基盤」に近いか確認する。
- 強みである「パスワードを共有せず権限委譲」が本当に評価軸になるか確認する。
- 注意点の「あくまで認可で、本人確認(認証)は別（→ OIDC）」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
向いている用途
こんな用途に向く
API へのアクセス委譲「〇〇でログイン」の基盤サードパーティ連携
公式サイト