// docs / baas security / auth0 hardening

Auth0 セキュリティチェックリスト: 22 項目

Auth0 は巨大な表面を持つ ID-as-a-Service プラットフォームです — アプリケーション、API (リソースサーバー)、テナント、アクション、ルール (レガシー)、コネクション、グラント。これらのいずれかの設定ミスは認証バイパスです。このチェックリストは、アプリケーション、コールバック / ログアウト許可リスト、トークンとリフレッシュローテーション、カスタムアクション、RBAC、異常検出、継続的監視にわたる 22 項目の監査です。各項目は Auth0 ダッシュボードで 10 分以内に検証可能です。

Clerk の同等チェックリストについてはClerk セキュリティチェックリストを参照してください。ID 層の設定ミスが AI ツールの盲点である理由の背景についてはAI コーディングツールがセキュリティギャップを残す理由を参照してください。

アプリケーションタイプとグラントタイプ

アプリケーションタイプと有効化されたグラントタイプは、Auth0 で最も影響度の高い設定です。これらを間違えると、フロントエンドコードでは閉じられない攻撃クラスが開きます。

ブラウザのみのアプリには Application Type = Single Page Application を、サーバーレンダリングアプリには Regular Web Application を使用。 間違ったタイプは間違ったグラントタイプを許可します — 例: SPA グラントが有効な Regular Web App は PKCE なし Implicit フローを有効にし、URL フラグメント経由でトークンを漏洩します。
すべてのアプリケーションで Implicit グラントタイプを無効化。 Dashboard → Application → Advanced Settings → Grant Types → Implicit のチェックを外します。Implicit フローは URL フラグメントでトークンを返し、それらはブラウザ履歴とアナリティクスにログされます。代わりに PKCE を伴う Authorization Code を使用します。
文書化された必要がない限り Password グラントを無効化。 Resource Owner Password Credentials (ROPC) グラントは、ユーザーのパスワードを自分で処理することを要求します — Auth0 を購入した理由のほとんどを台無しにします。レガシーシステムを統合する場合を除き、無効化してください。
すべての公開クライアントで PKCE を伴う Authorization Code を有効化。 Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256、OIDC Conformant = enabled。PKCE はコード傍受を防ぐためにモバイルアプリと SPA で必要です。

コールバックとログアウト URL 許可リスト

OAuth コールバックパスのオープンリダイレクトはトークン盗難プリミティブです。Auth0 の許可リストがあなたの唯一の防御です。

Allowed Callback URLs を正確な本番コールバックパスに設定 — ワイルドカードなし。 https://yourapp.com/* ではなく https://yourapp.com/callback。ワイルドカードコールバックは、攻撃者があなたのドメイン上の任意のサブパスにトークンをリダイレクトすることを許します。
Allowed Logout URLs を有限のリストに設定。 同じルール: 明示的な URL のみ。オープンログアウトリダイレクトは、攻撃者がポストログアウト状態に見えるフィッシングページを作ることを許します。
Allowed Web Origins を本番オリジンのみに設定。 サイレント認証 (隠し iframe 経由のトークン更新) に使用されます。ワイルドカードオリジンは、攻撃者ページがあなたのテナントに対してサイレント認証を実行することを許します。
API エンドポイント用の Allowed CORS origins を設定 (アプリケーション用ではなく)。 Tenant Settings → Advanced → Allowed CORS origins。デフォルトは空 (制限あり) です。自分が制御する明示的なオリジンのみを追加してください。

トークンとリフレッシュローテーション

トークン寿命、リフレッシュローテーション、署名アルゴリズムは、トークン漏洩の影響範囲を決めます。

Refresh Token Rotation を有効化。 Application → Refresh Token Settings → Rotation。各リフレッシュは新しいリフレッシュトークンを発行し、古いものを無効化します。絶対期限と組み合わせて、トークン盗難を封じ込めます。
Refresh Token Reuse Interval を 0 に設定 (または再生許容範囲が許す限り低く)。 再利用間隔は、同じウィンドウで 2 回トークンを使用することを許します — 特定の理由がない限りオフにしてください。
Absolute Refresh Token Expiry を無限ではなく 14〜30 日に設定。 Application → Refresh Token Expiration → Absolute Expiration。Auth0 は Inactivity のみがデフォルトで、つまりアイドルセッションは何年も持続できます。
JWT Signature Algorithm を RS256 に設定。 Application → Advanced → OAuth → JsonWebToken Signature Algorithm。RS256 は非対称署名を使用するため、クライアントはトークンを偽造できません。クライアント向けアプリケーションでは HS256 を決して使用しないでください。
API が受信するすべての JWT で aud と iss クレームを検証。 サーバー側で公式の Auth0 SDK を使用してください — これらを自動的に検証します。手書きの JWT 解析は通常オーディエンス検証をスキップし、これは認証バイパスです。

アクションとカスタムコード

Auth0 Actions (とレガシー Rules) はログインとその他のライフサイクルイベントでサーバー側で実行されます。リクエストコンテキスト全体にアクセスできます。ここでの安全でないコードはテナント全体の脆弱性です。

event.user や event.transaction をオブジェクト全体としてログしない。 これらにはメールアドレス、IP アドレス、その他の PII が含まれます。フィールドレベルのログのみを使用し、必要なものだけをログしてください。
API キーや Webhook URL にはシークレットストアを使用。 Actions → Edit → Secrets。アクションコードに API キーを文字列リテラルとしてインラインしないでください — そのコードはテナント上の Action エディタアクセスを持つ誰にでも見えます。
user_metadata や app_metadata として永続化する前に入力を検証。 event.body.name を user.user_metadata.display_name に書き込むセルフサービスアクションは、フロントエンドがそのフィールドをエスケープせずにレンダリングする場合、保存型 XSS ベクトルです。

RBAC とリソースサーバー

Auth0 RBAC を使用する場合、ロールから権限へのマッピングがあなたの認可層です。それを間違えると、認証済みの任意のユーザーが管理者エンドポイントにヒットできます。

Resource Servers (API) をその場ではなく Auth0 ダッシュボードで明示的に定義する。 各 API には識別子 (audience)、スコープ、署名設定があります。登録された API がなければ、すべてのトークンは暗黙の「Auth0 管理 API」用に発行されます — 間違ったオーディエンスです。
API ごとに権限を構成し、コード内で scope クレームでそれらを要求する。 アプリケーションロジック内でロールメンバーシップをチェックしないでください。アクセストークン内のスコープをチェックします。スコープは OAuth ネイティブの認可メカニズムです。
必要なロール / スコープを持たない認証済みユーザーが特権エンドポイントにヒットできないことをテスト。 通常ユーザーとしてサインインし、POST /api/admin/users/delete を呼び出そうとします。レスポンスは 403 でなければなりません。

異常検出とテナントログ

Auth0 は高シグナルイベントを発します。それらをログバッファに座らせるのではなく、チームにアラートするよう設定してください。

Attack Protection を有効化: Bot Detection、Brute Force、Suspicious IP Throttling。 Dashboard → Security → Attack Protection。それぞれは無料層ではデフォルトでオフです。本番では全部オンにしてください。
テナントログを SIEM またはアプリケーションログにストリーミング。 Dashboard → Monitoring → Streams。Auth0 はほとんどのプランで 30 日間ログを保持します。長期保持には自分のシステムへのストリームが必要です。
fcoa (失敗したクロスオリジン認証) と fp (失敗したログイン) の急増にアラート。 短時間でのこれらのバーストはクレデンシャルスタッフィングです。オンコールチャンネルにルーティングしてください。

次のステップ

本番 URL に対して FixVibe スキャンを実行してください — baas.clerk-auth0 チェックは JavaScript にバンドルされた Auth0 クライアントシークレットやその他の ID プロバイダ露出クラスをフラグします。Clerk の同等についてはClerk セキュリティチェックリストを参照してください。BaaS プロバイダ横断の全体像についてはBaaS 設定ミススキャナをお読みください。