どのような影響がありますか?
この移行による影響は、主に次の2点です。
- Management API のデフォルト (非推奨化)
POST /api/v2/clients でサードパーティアプリケーションを作成する場合、third_party_security_mode のデフォルト値は、2026年10月23日より permissive (従来の動作) から strict (強化されたセキュリティ制御) に変更されます。
Auth0 Dashboard で作成されたすべてのサードパーティアプリケーションには、すでに強化されたセキュリティ制御が適用されています。これは Auth0 Dashboard からは設定できません。
- Dynamic Client Registration (個別の設定)
Dynamic Client Registration を使用している場合、DCR クライアントは別のテナント設定 dynamic_client_registration_security_mode によって制御されます。これはこの非推奨化とは別であり、個別に設定方針を決める必要があります。
移行作業
サードパーティアプリケーションを確認する
移行方法を選ぶ前に、サードパーティアプリケーションがどのように動作しているかを確認し、現在どのような要件があるのかを把握してください。確認するポイントは次のとおりです。- 使用しているグラントタイプは何ですか? (authorization code、implicit、client credentials など)
- OIDC scopes (openid、profile、email) や IDトークンは必要ですか?
- Classic Login やレガシーエンドポイントを使用していますか?
- どのように作成されていますか? (Auth0 Dashboard/API から手動で、または DCR によって動的に)
strict または permissive) を示す third_party_security_mode プロパティがあります。
既存の permissive アプリケーションのセキュリティを強化する: API の API access policies を見直し、必要に応じて Require Client Grant に設定することを検討してください。これにより、permissive のサードパーティアプリケーションは、それらの API にアクセスするために明示的なグラントが必要になります。なお、このポリシーはファーストパーティアプリケーションにも適用されるため、変更前に既存の連携を確認してください。
強化されたセキュリティ制御が連携にどのような影響を与えるかを理解するには、以下の 機能比較 を確認し、ご自身のケースが 一般的なシナリオ のいずれかに当てはまるかを確認してください。FAQ セクションでも、この移行に関するよくある質問を取り上げています。
ステップ 1: 新しいサードパーティアプリケーションの作成方法を選択する
Management API 経由で作成する新しいサードパーティアプリケーションに、強化されたセキュリティ制御を適用するか、既存の動作を維持するかを決定します。この選択はPOST /api/v2/clients にのみ適用されます。Auth0 Dashboard で作成されたアプリケーションには、常に強化された制御が適用されます。
オプション A: 移行を完了する (推奨)
2026年10月23日までに移行を完了して、強化されたセキュリティ制御をデフォルトにしてください。この方法により、サードパーティアプリケーションを OAuth 2.1 のベストプラクティスに準拠させ、今後の機能に備えることができます。 互換性を検証するために、強化されたセキュリティ制御が適用されたテスト用のサードパーティアプリケーションを作成します。Auth0 CLI を使用していますか?まだの場合は、このコマンドを実行する前に CLI セッションをセットアップして認証してください。
tpc_ プレフィックスが付いた client_id と third_party_security_mode: "strict" が含まれます。
強化されたセキュリティ制御が適用されたサードパーティアプリケーションがAPIにアクセスするには、明示的なクライアントグラントが必要です。デフォルト権限では、すべてのサードパーティアプリケーションが自動的にアクセスできるAPIとスコープの基本セットを定義します。これは、アプリケーションごとに個別に権限を設定できない、動的に作成されるクライアントでは特に重要です。
また、個々のアプリケーション (client_id ごと) に対して固有の権限を定義し、デフォルトより広い、または狭いアクセスを付与することもできます。両方が設定されている場合は、アプリケーションごとの権限がデフォルト権限より優先されます。
- Auth0 Dashboard
- Management API
- Applications > APIs に移動します。
- サードパーティアプリケーションにアクセスを許可するAPIを選択します。
- Settings タブで、Default Permissions for Third Party Apps までスクロールします。
- User Access と/または Client Access で Authorized を選択します。
- 付与するスコープを選択します。
- Save をクリックします。
subject_type: "user") 用とマシン間アクセス (subject_type: "client") 用にそれぞれ別々に設定できます。
詳しくは、サードパーティアプリケーションのデフォルト権限を参照してください。
強化されたセキュリティ制御を有効にした状態で、サードパーティアプリケーションを作成するワークフローをテストします。次の点を確認してください。
- アプリケーションで
authorization_code、refresh_token、client_credentialsのグラントタイプを使用できること - 認可フローに PKCE が実装されていること
- OIDCスコープが不要であること
- Classic Login またはレガシーエンドポイントが不要であること
- テナントに、サードパーティのログインフローで実行が必要なアクティブな ルール がないこと。厳格なサードパーティアプリケーションではルールはサポートされておらず、エラーになります。ルールを使用している場合は、Actions への移行を検討するか、permissive mode を使用してください。

- Settings > Advanced に移動します。
- Migrations セクションまでスクロールします。
- Create Permissive Third-Party Clients by Default をオフにします。
- Save を選択します。
POST /api/v2/clients でサードパーティアプリケーションを作成する際は、次のいずれかを行えます。
third_party_security_modeパラメーターを省略する (拡張コントロールがデフォルトで適用されます) 、またはthird_party_security_mode: "strict"を明示的に設定する
/api/v2/clients エンドポイントへの POST リクエストで third_party_security_mode: "permissive" を明示的に指定する必要があります。
オプション B: 既存の動作をデフォルトとして維持する
既存の動作をデフォルトとしてサードパーティアプリケーションを引き続き作成する必要がある場合は、強化されたセキュリティ制御を導入する準備が整うまで、Create Permissive Third-Party Clients by Default トグルを有効のままにしておくことができます。 Create Permissive Third-Party Clients by Default トグルは有効のままです (トグル自体の操作は不要です) 。ただし、期限後はセキュリティモードを明示的に指定する必要があるため、それに対応できるようワークフローを準備しておく必要があります。 アプリケーションの作成コードを更新し、third_party_security_mode: "permissive" を明示的に渡すようにしてください。
期限前にこの方法をテストし、ワークフローでこの明示的なパラメーターを正しく処理できることを確認してください。
2026年10月23日をもって、既定で permissive のサードパーティクライアントを作成トグルは自動的にオフになります。既存の動作でアプリケーションを引き続き作成するには、すべての POST /api/v2/clients リクエストで third_party_security_mode: "permissive" を明示的に設定する必要があります。
third_party_security_mode パラメーターを省略すると、強化されたセキュリティ制御が既定で適用されます。
ステップ 2: Dynamic Client Registration の扱いを選択する
Dynamic Client Registration を使用している場合は、DCR クライアントのセキュリティモードを別途設定してください。これは Management API のデフォルト変更 とは独立しているため、いつでも設定できます。現在の DCR の動作を確認する
現在の DCR セキュリティモード設定を確認します。- Auth0 Dashboard
- Management API
- Settings > Advanced に移動します。Dynamic Client Registration (DCR) Security Mode で、現在の値を確認します。

DCR セキュリティモードを設定する
動的に登録されたクライアントに適用するセキュリティモードを選択します。 オプション A: DCR クライアントに強化されたセキュリティ制御を適用する (推奨)DCR で strict モードを有効にする前に、サードパーティアプリケーション向けのデフォルト権限を設定してください。デフォルト権限が設定されていない場合、DCR クライアントはいずれの API にもアクセスできません。
dynamic_client_registration_security_mode を strict に設定します。
オプション B: DCR クライアントの既存の動作を維持する
dynamic_client_registration_security_mode を permissive のままにするか、permissive に設定します。
詳しくは、Dynamic Client Registrationを参照してください。
機能比較
次の表では、各セキュリティモードで利用可能な機能を比較しています。よくあるケース
シナリオ 1: 最新の OAuth を使用するパートナー連携
状況: PKCE を使用する認可コードフローを利用し、API にアクセスするパートナー連携があります。 推奨事項: 強化されたセキュリティ制御 (オプション A) を採用してください。これは最新の OAuth 実装と完全に互換性があり、セキュリティ強化のメリットも得られます。 手順:- API のデフォルトのAPI権限を設定する
third_party_security_mode: "strict"を指定してパートナーアプリケーションを作成できるかテストする- 移行トグルをオフにして移行を完了する
シナリオ 2: OIDC が必要なアプリケーション
状況: サードパーティアプリケーションで、OIDC スコープ (openid、profile、email) または ID トークンが必要です。 推奨事項: サードパーティアプリケーション向けの OIDC サポートは、今後のリリースで提供される予定です。それまでは、既存の動作 (オプション B) を維持するか、API スコープ付きアクセストークンに移行してください。 手順:- OIDC を使用する必要がある場合は、移行トグルを有効のままにし、アプリケーションの作成時に
third_party_security_mode: "permissive"を明示的に指定します - または、OIDC スコープではなく API スコープを使用するように連携を更新します
シナリオ 3: Dynamic Client Registration (MCP、AI エージェント)
状況: AI エージェント、MCP サーバー、または開発者ポータルのアプリケーションで DCR を使用しています。 推奨事項:dynamic_client_registration_security_mode: "strict" を設定し、デフォルトのAPI権限を設定します。MCP クライアント (Claude Code、VS Code) は強化されたセキュリティ制御に対応しています。
手順:
- デフォルトのAPI権限を設定する
- Management API で
dynamic_client_registration_security_mode: "strict"を設定する - DCR 登録でテストする
- DCR クライアントが access token を取得できることを確認する
シナリオ 4: Classic Login を使用するアプリケーション
状況: サードパーティアプリケーションで、Universal Login ではなく Classic Login を使用しています。 推奨事項: 強化されたセキュリティ制御が適用されるサードパーティアプリケーションでは、Classic Login はサポートされていません。Universal Login に移行するか、既存の動作を維持してください。 手順:- 推奨: 強化された制御を導入する前に、Universal Login に移行する
- 代替: 移行トグルを有効のままにし、
third_party_security_mode: "permissive"を明示的に指定する
シナリオ5: Organizations を使用するサードパーティアプリケーション
状況: サードパーティアプリケーション (パートナー連携、AI エージェント) で、組織コンテキスト内のユーザーを認証したい場合。 推奨事項: 強化されたセキュリティ制御を採用します。既存の動作では、サードパーティアプリケーションで Organizations を利用できません。サードパーティアクセスを許可する各組織でthird_party_client_access: allow を設定します。
手順:
- サードパーティアプリケーションで強化されたセキュリティ制御 (
third_party_security_mode: "strict") を使用していることを確認します。 - 組織で
third_party_client_access: allowを設定します。
- 組織に必要な接続を有効にします。
- 外部アプリケーションから
organizationパラメータが渡されることを前提にできないため、ユーザーが正しい組織コンテキストにルーティングされるよう、Prompt for Organization または Organization Domain Discovery を設定します。
トラブルシューティング
移行中によく発生するエラーの解決方法については、サードパーティアプリケーションのトラブルシューティングを参照してください。よくある質問
既存のアプリケーションのセキュリティモードは変更できますか?
いいえ。third_party_security_mode はアプリケーションの作成時に設定されるため、後から変更することはできません。別のセキュリティモードを使用するには、新しいアプリケーションを作成してください。
既存のサードパーティアプリケーションはどうなりますか?
何も変わりません。既存のサードパーティアプリケーションは、現在とまったく同じように引き続き動作します。この移行で影響を受けるのは、新しく作成されるアプリケーションのデフォルト設定だけです。同じテナント内で両方のセキュリティモードを使用できますか?
はい。一部のサードパーティアプリケーションには強化されたセキュリティ制御を適用し、他のアプリケーションには従来どおりの動作を維持できます。セキュリティモードはアプリケーションごとに設定されます。Dynamic Client Registration については?
DCR は、dynamic_client_registration_security_mode という別のテナント設定で制御されます。これは非推奨化とは別のものであり、個別に設定を判断する必要があります。詳しくは、Dynamic Client Registration をご覧ください。
期限後も既存の動作でアプリケーションを作成できますか?
はい。ただし、Management API を使用する場合に限ります。各アプリケーションの作成時に、third_party_security_mode: "permissive" を明示的に設定してください。Auth0 Dashboard では、既存の動作でアプリケーションを作成することはできません。