OAuth 2.0 とは

OAuth 2.0 とは、サードパーティのアプリケーションに対して、ユーザーのパスワードを共有せずにリソースへの限定的なアクセス権を付与する認可フレームワークです。RFC 6749 で標準化されています。

身近な例として、「Google でログイン」「GitHub でログイン」といったソーシャルログインがあります。この場合、利用したいサービスに Google のパスワードを教えることなく、Google が保持するプロフィール情報 (名前、メールアドレスなど) へのアクセスを許可できます。

重要な点として、OAuth 2.0 は「認可 (Authorization)」のフレームワークであり、「認証 (Authentication)」のプロトコルではありません。認証機能が必要な場合は、OAuth 2.0 の上に構築された OpenID Connect (OIDC) を使用します。シングルサインオンの多くは OIDC を基盤としています。

OAuth 2.0 の登場人物とフロー

OAuth 2.0 には 4 つの役割 (ロール) が登場します。

リソースオーナー: データの所有者 (通常はユーザー本人)
クライアント: ユーザーのデータにアクセスしたいアプリケーション
認可サーバー: アクセストークンを発行するサーバー (例: Google の認可エンドポイント)
リソースサーバー: ユーザーのデータを保持するサーバー (例: Google の API サーバー)

最も一般的な Authorization Code Flow の流れは以下のとおりです。

ユーザーがクライアントアプリの「Google でログイン」ボタンをクリック
クライアントがユーザーを Google の認可エンドポイントにリダイレクト
ユーザーが Google のログイン画面で認証し、アクセス許可に同意
Google が認可コード (一時的なコード) をクライアントに返す
クライアントが認可コードをアクセストークンに交換
クライアントがアクセストークンを使って Google API からユーザー情報を取得

この仕組みにより、クライアントアプリはユーザーの Google パスワードを一切知ることなく、許可された範囲のデータにアクセスできます。

スコープによるアクセス制御

OAuth 2.0 の重要な概念が「スコープ」です。スコープはアクセストークンに付与される権限の範囲を定義します。

たとえば Google の OAuth 2.0 では、以下のようなスコープが定義されています。

profile: 名前やプロフィール画像の読み取り
email: メールアドレスの読み取り
https://www.googleapis.com/auth/drive.readonly: Google Drive の読み取り専用アクセス
https://www.googleapis.com/auth/calendar: Google カレンダーの読み書き

ユーザーが同意画面で確認するのは、このスコープの一覧です。アプリが要求するスコープが広すぎる場合 (例: カレンダーアプリなのに連絡先へのアクセスを要求する) は、不必要なデータ収集の可能性があるため注意が必要です。データ最小化の原則に基づき、アプリが必要最小限のスコープのみを要求しているか確認しましょう。

OAuth 2.0 のセキュリティ上の注意点

OAuth 2.0 を安全に利用するために、ユーザーとして知っておくべきポイントがあります。

同意画面を必ず確認する: アプリが要求する権限 (スコープ) を確認し、不必要に広い権限を要求するアプリには同意しない
定期的にアプリ連携を見直す: Google、GitHub などのアカウント設定で、連携済みのサードパーティアプリを確認し、使わなくなったアプリのアクセス権を取り消す
PKCE (Proof Key for Code Exchange) の重要性: モバイルアプリや SPA (Single Page Application) では、認可コードの横取り攻撃を防ぐ PKCE 拡張が必須。OAuth 2.1 では PKCE がすべてのクライアントで必須化される予定
CSRF 対策: state パラメータを使用して、認可リクエストとコールバックの対応を検証する。これにより、攻撃者が用意した認可コードをユーザーに使わせる攻撃を防止できる
リダイレクト URI の厳密な検証: 認可サーバーは登録済みのリダイレクト URI のみを許可し、オープンリダイレクタの脆弱性を防ぐ

よくある誤解

OAuth 2.0 はログイン (認証) のためのプロトコル: OAuth 2.0 は認可 (リソースへのアクセス許可) のフレームワークであり、認証 (ユーザーの本人確認) のプロトコルではない。認証には OAuth 2.0 の上に構築された OpenID Connect (OIDC) を使用する。「Google でログイン」は正確には OIDC による認証。
ソーシャルログインを使えばパスワード漏洩のリスクがなくなる: ソーシャルログインにより個別サービスのパスワードは不要になるが、Google や GitHub のアカウント自体が侵害されれば、連携する全サービスが影響を受ける。SSO アカウントには二要素認証を必ず設定し、定期的にアプリ連携を見直すことが重要。

OAuth 2.0