OAuth、JWT、ゲートウェイ:セキュリティの役割を分ける

要点

OAuth 2.0は委任された認可を扱い、OpenID Connectは認証層を加えます。JWTはトークン形式、ゲートウェイは制御点であり、役割が異なります。

セキュリティキー2個、白紙のカード、えんじ色の資料がある架空の無人本人確認室
この記事の内容

ツールより先に役割を選ぶ

OAuthアクセストークンは不透明な値でもJWTでも構いません。JWTをデコードしても真正性は検証されず、署名済みJWTの内容が自動的に暗号化されるわけでもありません。ゲートウェイはサービス内の業務認可を代替しません。

要素役割明示する限界
OAuth 2.0認可の委任。単独では利用者ログインのプロトコルではない。
OpenID ConnectOAuth 2.0上の認証。プロファイルとトークンの検証が必要。
JWTクレームの形式。デコード、署名、暗号化は別。
APIゲートウェイ入口の共通制御。オブジェクトごとの権限を代替しない。

プロトコルと各アクセスを検証する

  • クライアントに適したフローを選びます。利用者の操作経路では、保守されたライブラリーと厳密なリダイレクト管理を使い、認可コードとPKCEの現行推奨に従います。
  • 受け入れるJWTの署名、許可アルゴリズム、発行者、対象、プロファイルの時間条件を確認します。別用途のトークンは拒否します。
  • 各オブジェクト、操作、組織への権限を確認します。架空データでアカウント間アクセスを試験し、広いロールやスコープだけで判断しません。

期限、失効、事故も計画する

更新、鍵ローテーション、秘密情報の喪失、失効方法を文書化します。ローカル検証は遠隔の失効を自動的に知りません。トークン情報とログを最小化します。JWTや割当量だけで安全性や準拠を保証できません。

一次資料

ゲートウェイはオブジェクト認証を代替するものではありません。

APIは、トークンが自身宛てであることと、呼び出し元がオブジェクトに対して操作を実行できることの両方を検証する必要があります。有効なJWT署名やOAuthサインインの成功は、これらの権限を確立するものではありません。隣接するIDと特権関数をテストしてください。

  • 他のユーザー宛ての有効なトークンは拒否してください。
  • クロスアカウントアクセス、プライベートフィールド、および管理操作をテストしてください。
  • トークンをログに書き込まずに、有効期限とロール変更をテストしてください。

一次資料:IETF — RFC 9700, OAuth 2.0 Security Best Current Practice. 関連する方法:実践ガイドを読む.

パスキー:ドメインとRP IDの変更を準備する

アカウント、ウェブのオリジン、RP IDを分け、認証情報を黙って付け替えない移行を計画します。

  • 旧・新のオリジン、RP ID、対応するアカウントを記録します。同じアカウント名でもパスキーが別のRP IDに有効になるわけではありません。WebAuthnの許される組合せと移行中のログイン経路を確認します。
  • 許可されたテスト環境で適切なライブラリを使い、チャレンジ、オリジン、RP ID、アカウントの関連付けを確認します。想定外のオリジンとチャレンジの再利用を試します。RP IDが変わる場合は認証済みの新規登録を準備し、行のコピーを鍵の移行と扱いません。
  • 旧認証情報だけを持つ利用者、復旧、既存セッションを試します。確認した戻し方とともに経路の開設・廃止順を決めます。新ドメインでの登録成功は全旧セッションの失効を証明しません。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

期待される判断

架空例:アカウントは同じでもold.exampleから別のRP IDのnew.exampleへ移ります。旧認証情報を黙って付け替えず、新規登録は計画した認証済み経路で行います。

W3C — Web Authentication Level 2

データベースの編集でパスキーのRP IDを変更できますか?

できません。RP IDは認証情報の検証される範囲の一部です。新しい範囲の有効な登録と認証済みのアカウント対応付けを準備します。

一次資料:W3C — Web Authentication Level 2. 関連する方法:実践ガイドを読む.

TLS更新:実際に提示される証明書を確認する

更新をTLS終端とクライアントまで追跡してから変更を完了します。

  • 名前、CDN、負荷分散、プロキシ、内部接続を列挙し、提示証明書、チェーン、有効期限、担当者を記録します。発行成功は全ノードへの導入を証明しません。秘密鍵を保護し台帳に含めません。
  • 提供される場合は事業者のテスト環境で自動化を試します。検証チャレンジ、SAN名、保護された保存先、再読み込みを確認します。鍵方針上使える証明書がある場合は起動ごとの発行を避けます。
  • 対応クライアントと関連経路で名前、日付、信頼チェーンを確認します。TLS検証は有効に保ちます。スケジューラーだけでなく提示証明書の期限を監視します。戻すには有効証明書と侵害されていない鍵が必要で、それ以外は修正または隔離します。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}

期待される判断

架空例:更新は成功しましたが二つのプロキシの一つが期限切れ証明書を提示します。未完了として修正し、TLS検証を無効化せず経路を確認します。

Let’s Encrypt — Integration Guide

一次資料:Let’s Encrypt — Integration Guide. 関連する方法:実践ガイドを読む.

CISA KEVカタログを調べる

この言語版の詳しい参照メモは英語で提供しています。

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

カタログと方法を見る →

CISA KEV · 2026.11.06 · Documentary review : 2026-11-07

拡張機能:権限とアクセス

この言語版の詳しい参照メモは英語で提供しています。

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent