Skip to main content
2026年10月23日より、Auth0はManagement API経由で新規作成されるサードパーティアプリケーションのデフォルトのセキュリティモードを変更します。今後、サードパーティアプリケーションでは、OAuth 2.1のベストプラクティスに沿った強化されたセキュリティ制御がデフォルトで適用されます。
この変更の対象となるのは、2026年4月23日より前からサードパーティアプリケーションを使用していたテナントのみで、影響を受けるのは新規作成されるアプリケーションに限られます。既存のサードパーティアプリケーションは、変更対応なしでこれまでどおり引き続き動作します。
Auth0は、すべての新規サードパーティアプリケーションで強化されたセキュリティ制御を採用することを強く推奨しています。強化された制御では、API認可の明示化、PKCEの必須化、OAuth 2.1とセキュリティのベストプラクティスに沿った厳選された機能セットが提供されます。さらに、強化された制御を備えたアプリケーションは、将来的にアプリケーション単位のレート制限や、より使いやすい管理ツールなどの機能も利用できるようになります。ただし、特定のユースケースで必要な場合は、既存の動作を維持することも可能です。 サードパーティアプリケーションの詳細については、サードパーティアプリケーションを参照してください。各モードで利用できる機能の詳細な比較については、Feature comparisonを参照してください。特定の連携パターンに関するガイダンスについては、Common scenariosを参照してください。

​
どのような影響がありますか？

この移行による影響は、主に次の2点です。

​
1. Management API のデフォルト (非推奨化)

POST /api/v2/clients でサードパーティアプリケーションを作成する場合、third_party_security_mode のデフォルト値は、2026年10月23日より permissive (従来の動作) から strict (強化されたセキュリティ制御) に変更されます。 Auth0 Dashboard で作成されたすべてのサードパーティアプリケーションには、すでに強化されたセキュリティ制御が適用されています。これは Auth0 Dashboard からは設定できません。

​
2. 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 によって動的に)
サードパーティアプリケーションの数が少ない場合は、Auth0 Dashboard または Management API を使って個別に確認できます。各アプリケーションには、現在のセキュリティモード (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 で作成されたアプリケーションには、常に強化された制御が適用されます。 2026年10月23日までに移行を完了して、強化されたセキュリティ制御をデフォルトにしてください。この方法により、サードパーティアプリケーションを OAuth 2.1 のベストプラクティスに準拠させ、今後の機能に備えることができます。
1. 強化されたセキュリティ制御をテストする
互換性を検証するために、強化されたセキュリティ制御が適用されたテスト用のサードパーティアプリケーションを作成します。
Auth0 CLI を使用していますか？まだの場合は、このコマンドを実行する前に CLI セッションをセットアップして認証してください。
レスポンスには、tpc_ プレフィックスが付いた client_id と third_party_security_mode: "strict" が含まれます。
2. デフォルト権限を設定する
強化されたセキュリティ制御が適用されたサードパーティアプリケーションがAPIにアクセスするには、明示的なクライアントグラントが必要です。デフォルト権限では、すべてのサードパーティアプリケーションが自動的にアクセスできるAPIとスコープの基本セットを定義します。これは、アプリケーションごとに個別に権限を設定できない、動的に作成されるクライアントでは特に重要です。 また、個々のアプリケーション (client_id ごと) に対して固有の権限を定義し、デフォルトより広い、または狭いアクセスを付与することもできます。両方が設定されている場合は、アプリケーションごとの権限がデフォルト権限より優先されます。
  1. Applications > APIs に移動します。
  2. サードパーティアプリケーションにアクセスを許可するAPIを選択します。
  3. Settings タブで、Default Permissions for Third Party Apps までスクロールします。
  4. User Access と/または Client Access で Authorized を選択します。
  5. 付与するスコープを選択します。
  6. Save をクリックします。
サードパーティアプリケーション向けのデフォルト権限は、ユーザーアクセス (subject_type: "user") 用とマシン間アクセス (subject_type: "client") 用にそれぞれ別々に設定できます。 詳しくは、サードパーティアプリケーションのデフォルト権限を参照してください。
3. 互換性を検証する
強化されたセキュリティ制御を有効にした状態で、サードパーティアプリケーションを作成するワークフローをテストします。次の点を確認してください。
  • アプリケーションで authorization_code、refresh_token、client_credentials のグラントタイプを使用できること
  • 認可フローに PKCE が実装されていること
  • OIDCスコープが不要であること
  • Classic Login またはレガシーエンドポイントが不要であること
  • テナントに、サードパーティのログインフローで実行が必要なアクティブな ルール がないこと。厳格なサードパーティアプリケーションではルールはサポートされておらず、エラーになります。ルールを使用している場合は、Actions への移行を検討するか、permissive mode を使用してください。
互換性の問題が見つかった場合は、Troubleshoot サードパーティアプリケーション を参照してください。
4. 移行を完了する
互換性を確認したら、Create Permissive Third-Party Clients by Default トグルをオフにして移行を完了します。
Create Permissive Third-Party Clients Bt Default
Auth0 Dashboard で次の操作を行います。
  1. Settings > Advanced に移動します。
  2. Migrations セクションまでスクロールします。
  3. Create Permissive Third-Party Clients by Default をオフにします。
  4. Save を選択します。
移行の完了後、POST /api/v2/clients でサードパーティアプリケーションを作成する際は、次のいずれかを行えます。
  • third_party_security_mode パラメーターを省略する (拡張コントロールがデフォルトで適用されます) 、または
  • third_party_security_mode: "strict" を明示的に設定する
2026年10月23日以降: 対象となるすべてのテナントで、Create Permissive Third-Party Clients by Default トグルは自動的にオフになります。既存の動作でアプリケーションを作成するには、/api/v2/clients エンドポイントへの POST リクエストで third_party_security_mode: "permissive" を明示的に指定する必要があります。

​
オプション B: 既存の動作をデフォルトとして維持する

既存の動作をデフォルトとしてサードパーティアプリケーションを引き続き作成する必要がある場合は、強化されたセキュリティ制御を導入する準備が整うまで、Create Permissive Third-Party Clients by Default トグルを有効のままにしておくことができます。
このオプションを選ぶと現在のワークフローは維持されますが、強化された制御によるセキュリティ上のメリットは得られません。Auth0 では、すべての新しいサードパーティアプリケーションに対して強化されたセキュリティ制御を導入することを強く推奨しています。
期限前
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 で強化されたセキュリティ制御を有効にする前に、サードパーティアプリケーション向けの デフォルトのAPI権限 を設定していることを確認してください。デフォルト権限が設定されていないと、DCR クライアントはどの API にもアクセスできません。

​
現在の DCR の動作を確認する

現在の DCR セキュリティモード設定を確認します。
  1. Settings > Advanced に移動します。Dynamic Client Registration (DCR) Security Mode で、現在の値を確認します。
DCR Security Mode ドロップダウンが表示された Dashboard の Advanced Tenant Settings

​
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 実装と完全に互換性があり、セキュリティ強化のメリットも得られます。 手順:
  1. API のデフォルトのAPI権限を設定する
  2. third_party_security_mode: "strict" を指定してパートナーアプリケーションを作成できるかテストする
  3. 移行トグルをオフにして移行を完了する

​
シナリオ 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) は強化されたセキュリティ制御に対応しています。 手順:
  1. デフォルトのAPI権限を設定する
  2. Management API で dynamic_client_registration_security_mode: "strict" を設定する
  3. DCR 登録でテストする
  4. 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 を設定します。 手順:
  1. サードパーティアプリケーションで強化されたセキュリティ制御 (third_party_security_mode: "strict") を使用していることを確認します。
  2. 組織で third_party_client_access: allow を設定します。
  1. 組織に必要な接続を有効にします。
  2. 外部アプリケーションから 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 では、既存の動作でアプリケーションを作成することはできません。

​
今後の機能は既存の動作でも利用できますか？

今後提供される一部の機能 (アプリケーション単位のレート制限など) は、強化されたセキュリティ制御が適用されたアプリケーションでのみ利用できます。

​
詳しくはこちら