Cyber Security Academy · レッスン

OAuth 2.0フロー

Q: 「OAuth 2.0フロー」で何を学びますか？

認可グラントとトークンを学びます。 ブラウザで直接実行するハンズオンコードでCyber Security Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

認可グラントとトークンを学びます。

「OAuth 2.0フロー」はCoddyKit上の無料Cyber Security Academyレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはCyber Security Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cyber Security Academyコースには全4レッスンが含まれています。

OAuth 2.0が実際に解決すること

OAuth 2.0は委任認可のフレームワークです。ユーザーは、パスワードを共有せずに、別のサービス上にある自分のリソースへの限定的なアクセスをサードパーティアプリケーションに許可できます。

これは認可（アプリが何を実行できるか）に関するものであり、認証（ユーザーが誰であるか）に関するものではありません。
アプリが受け取るのはスコープが設定された access_token であり、ユーザーの認証情報を受け取ることはありません。

防御側は、OAuth だけでは本人確認にならないことを覚えておく必要があります。アクセストークンをログインの証明として扱うのは、OIDC が解決する典型的な誤りです。

4つのロール

すべての OAuth フローには4つのロールが関わります。脅威モデリングには、これらを正しく対応付けることが不可欠です。

Resource Owner データを所有するユーザー
Client アクセスを要求するアプリ
Authorization Server (AS) 同意後にトークンを発行するサーバー
Resource Server (RS) 保護されたデータを保持し、トークンを検証する API

これらのロールの間には信頼境界があります。侵害されたクライアントや過度に寛容な AS は、連鎖全体を危うくします。

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Authorization Code Grant

Authorization Codeグラントは、Web アプリとモバイルアプリに推奨されるフローです。ユーザー向けのリダイレクトと、秘密のトークン交換を分離します。

ユーザーは AS にリダイレクトされ、認証と同意を行う
AS は、登録済みのリダイレクト URI に短時間だけ有効な code を返す
クライアントは、バックチャネルを介してコードを（サーバー側で）トークンと交換する

トークンはバックチャネルで取得されるため、ブラウザーのアドレスバーや履歴に表示されることはありません。

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE：Proof Key for Code Exchange

PKCE（RFC 7636）は Authorization Code グラントを強化するもので、現在では confidential client を含むすべてのクライアントに推奨されています。

クライアントはランダムな code_verifier を生成し、そのハッシュを code_challenge として送信する
トークン交換時には、元の verifier を提示する必要がある

これによりコードが最初の要求元に紐付けられるため、認可コードを傍受した攻撃者がそれを引き換えることを防げます。

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Client Credentials Grant

Client Credentialsグラントは、ユーザーが関与しないマシン間アクセス（バックエンドサービスが API を呼び出す場合）に使用します。

クライアントは自身の認証情報で認証し、アクセストークンを受け取る
通常、ユーザーの同意はなく、リフレッシュトークンもない

これらのトークンのスコープは厳密に設定し、クライアントシークレットをローテーションしてください。エンドユーザーになりすますために、このフローを使用してはいけません。

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

アクセストークンとリフレッシュトークン

OAuth では、存続期間と取り扱いルールが大きく異なる、主に2種類のトークンが発行されます。

アクセストークン 短時間だけ有効で、呼び出しのたびにリソースサーバーへ送信する。ベアラー資格情報として扱う
リフレッシュトークン 長期間有効で、AS に対してのみ使用し、新しいアクセストークンを取得する

リフレッシュトークンは価値の高い情報です。安全に保管し、クライアントに紐付け、失効にも対応してください。

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

ベアラートークンと通信

ほとんどの OAuth アクセストークンは ベアラートークンです。トークンを持っている人は、現金のようにそれを使用できます。

必ず TLS 経由で送信し、ログやリファラーに漏れる可能性がある URL には決して含めないでください。
Authorization ヘッダーで送信してください。
高リスク API では、送信者制約付きトークン（DPoP、mTLS）の利用を検討してください。

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

Implicit Grant は非推奨です

従来の Implicit グラントは、リダイレクト URI のフラグメントにトークンを直接返していました。現在は OAuth 2.0 Security BCP で 非推奨とされ、OAuth 2.1 では削除されています。

トークンはブラウザー履歴、リファラーヘッダー、ログを通じて漏洩する可能性がありました。
バックチャネルがないため、クライアント認証が弱くなっていました。

代わりに SPA では Authorization Code with PKCE を使用してください。

state パラメーターと CSRF

state パラメーターは、リダイレクト処理を CSRF から保護します。クライアントはランダムな値を生成してセッションに保存し、コールバック時に検証します。

返された state が一致しない場合は、レスポンスを拒否してください。
これにより、攻撃者が被害者のセッションに自分の認可コードを注入するのを防げます。

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

スコープと最小権限

スコープは、トークンが付与するアクセス権の粒度を表します。あらゆる段階で最小権限を適用してください。

機能に必要なスコープだけを要求してください（adminではなく read:profile）。
リソースサーバーは、有効なトークンを信頼するだけでなく、各エンドポイントでスコープを強制しなければなりません。

過度に広い同意は現実によくあるリスクです。ユーザーは必要以上の権限を要求するアプリを承認してしまいます。

OAuth でよくある設定ミス

OAuth のインシデントの多くは、プロトコル自体ではなく設定に起因します。

オープンリダイレクト / 緩すぎる redirect_uri の照合により、攻撃者がコードを盗めてしまいます。
state または PKCE がないと、CSRF やコードインジェクションが可能になります。
失効機能のない、長期間有効なアクセストークンを使用していること。
アクセストークンを認証アサーションとして扱うこと。

リダイレクト URI は正確な値で登録し、厳密に検証してください。

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

クイックチェック: SPA 認証の保護

以下のシナリオに適した、最新のフローを選択してください。

振り返り: OAuth 2.0 のフロー

重要なポイント:

OAuth 2.0 は委任認可であり、認証ではありません。
4 つの役割は、リソース所有者、クライアント、認可サーバー、リソースサーバーです。
Authorization Code + PKCE は、Web、モバイル、SPA でのデフォルトです。
Client Credentials は、マシン間アクセスに使用します。
state、厳密なリダイレクト URI の照合、短期間で失効するアクセストークン、あらゆる通信での TLS によって保護してください。
Implicit と Password グラントは非推奨です。

よくある質問

「OAuth 2.0フロー」レッスンは無料ですか？

はい。「OAuth 2.0フロー」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Cyber Security Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cyber Security Academyコースには全4レッスンが含まれています。

「OAuth 2.0フロー」で何を学びますか？

認可グラントとトークンを学びます。ブラウザで直接実行するハンズオンコードでCyber Security Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Cyber Security Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのCyber Security Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「OAuth 2.0フロー」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このCyber Security Academyレッスンでコードを書いて実行できますか？

はい。すべてのCyber Security Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Cyber Security Academyに戻る