OAuth 2.0

OAuth 2.0 は、ユーザーのパスワードを確認することなく、あるアプリケーションがユーザーに代わって別のアプリケーションのリソースに限定的にアクセスできるようにする承認フレームワークです。古典的な使用例: Google カレンダーを読み取る必要があるカレンダー アプリでは、Google パスワードを入力する必要はありません。 OAuth を使用すると、代わりにスコープ指定された取り消し可能なトークンをアプリに付与できます。

アクター

OAuth フローの 4 つの役割:

• リソース所有者 — あなた、どこかにデータを持つユーザー
• Client — アクセスを必要とするアプリケーション(例: サードパーティのカレンダー ビューア)
• 認可サーバー — あなたを認証し、トークンを発行するサービス (例: Google の OAuth エンドポイント)
• リソース サーバー — データを保持する API (例: Google カレンダー) API)

認証コード フロー

簡略化された標準的なサーバー側フロー:

1. クライアント アプリで [Google カレンダーに接続] をクリックします。
2. クライアントは、パラメーター client_id、redirect_uri、scope を使用してブラウザを Google の認証サーバーにリダイレクトします。 (calendar.read)、状態 (CSRF トークン)。
3. まだログインしていない場合は、Google に認証します。
4. Google に同意画面が表示されます:「CalendarViewer がカレンダーの読み取りを要求しています。許可しますか?」
5. 「許可」をクリックします。 Google は、ワンタイム認証コードを使用してブラウザをクライアントの redirect_uri にリダイレクトします。
6. クライアントのサーバー側コードは、Google のトークン エンドポイントを直接呼び出すことにより、アクセス トークンの認証コード (およびそのクライアント シークレット) を交換します。
7. クライアントは、アクセス トークンを使用して、ユーザーに代わって Google Calendar API を呼び出します。
8. アクセス トークンの有効期限が切れたとき

重要なセキュリティ プロパティ: パスワードがクライアント アプリに影響することはありません。クライアントは、Google のアカウント ダッシュボードでいつでも取り消すことができるスコープ付きトークンを取得します。

OAuth 2.0 対 OAuth 2.1 対 OIDC

• OAuth 2.0 は 2012 年の標準 (RFC 6749) です。それ以降、いくつかの拡張 RFC とベスト プラクティス ドキュメントが追加されました。
• OAuth 2.1 (2026 年時点のドラフト) は、現在のベスト プラクティスを 1 つの仕様に統合します (必須の PKCE、削除された暗黙的フローなど)。
• OpenID Connect (OIDC) は ID レイヤーです。 OAuth 2.0 の上に。 OAuth 単独では、不透明なアクセス トークンが提供されます。 OIDC は、ユーザーを認証する ID トークン (JWT) を追加します。ほとんどの「サインイン...」ボタンは、プレーンな OAuth ではなく、OIDC を使用します。

付与タイプ

OAuth 2.0 では、さまざまなシナリオ向けにいくつかのフローが定義されています。

• 認証コード - 上で説明した標準のサーバー側フロー。 PKCE 拡張機能を使用し、モバイル アプリや SPA アプリでも使用されます。
• Implicit Flow (非推奨) — URL フラグメントを介して直接アクセス トークンを発行しました。トークン漏洩に対して脆弱です。認証コード + PKCE.
• リソース所有者パスワード資格情報 (めったに使用されません) に置き換えられます - クライアントはユーザーのパスワードを収集し、それをトークンと交換します。従来の移行シナリオでのみ使用してください。
• Client Credentials — ユーザーがいないマシン間の場合。クライアントは自身を認証し、独自のリソースのトークンを取得します。
• デバイス コード — ブラウザーのないデバイス (TV、IoT) 用。デバイスはコードを表示します。ユーザーは電話またはラップトップから認証します。
• リフレッシュ トークン - ユーザーの操作なしで、有効期間の長いリフレッシュ トークンを新しいアクセス トークンと交換します。

PKCE: 必須の拡張機能

PKCE (コード交換用の証明キー、 「ピクシー」と発音します）は、認証コード傍受攻撃を防ぎます。クライアントはランダムなシークレットを生成し、それをハッシュし、そのハッシュを認可リクエストに含めて送信します。コードを交換するときは、元のシークレットが送信されます。認可サーバーはハッシュが一致することを検証します。コードを傍受した攻撃者は、元のシークレットがなければコードを交換できません。

PKCE は現在、パブリック (ブラウザ、モバイル) と機密 (サーバーサイド) の両方のすべての OAuth クライアントに対して必須とみなされます。

Scopes

Token は、特定のスコープ、つまり実行が許可されるアクションで発行されます。 Google の一般的なスコープは、https://www.googleapis.com/auth/calendar.readonly のようになります。クライアントはスコープを要求します。ユーザーは同意画面でそれらを確認し、承認または拒否します。最小特権の原則: 実際に必要なスコープのみを要求します。

一般的な OAuth 攻撃

• リダイレクトを開く。 redirect_uri パラメーターが正しく設定されていないと、攻撃者は認証コードを自分のサーバーにリダイレクトできます。
• 状態パラメーターの省略。 状態値が関連付けられていない場合ユーザー セッションに対して、OAuth フローは CSRF に対して脆弱です。攻撃者は被害者をだまして、攻撃者のアカウントを被害者のセッションにリンクする OAuth フローを完了させます。
• ブラウザー履歴でのトークン漏洩 (暗黙的フローの主な弱点)
• XSS によるトークン盗難クライアント アプリがトークンを localStorage に保存しており、XSS の脆弱性がある場合、攻撃者はトークンを盗むことができます。
• 同意画面のフィッシング 攻撃者は、機密スコープを要求する悪意のある OAuth クライアントを登録します。ユーザーは、同意画面で「許可」をクリックすることを条件に、精査することなくアクセスを許可します。

ユーザーとして行うべきこと

• Google/Apple/Microsoft/Facebook/GitHub アカウント設定で接続されているアプリを定期的に確認します。使用しないものは取り消してください。
• アクセスを許可する前に、同意画面のスコープを読んでください。 「カレンダーの管理」は「カレンダーの表示」とは異なります。
• たとえ馴染みのあるワークフロー中に表示されたとしても、見覚えのないアプリからの OAuth リクエストには懐疑的になってください。