> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> お使いのテナントに影響する可能性のある、現在移行が進行中のすべての非推奨項目を一覧表示します。

# 非推奨事項と移行

以下に記載されているすべての非推奨項目について、現在、お客様の環境を新しい動作へ順次移行しています。サービスの中断を避けるため、必要な対応が完了しているかを確認するうえで、内容をよくご確認ください。また、非推奨機能の使用によって発生したエラーがないか、テナントのログを検索して確認することもできます。

ご不明な点がある場合は、[Community](https://community.auth0.com/) にアクセスするか、[Support Center でチケットを作成](https://support.auth0.com)してください。詳細については、[移行プロセス](/docs/ja-jp/troubleshoot/product-lifecycle/migration-process)もご覧ください。

<div id="enhanced-security-for-third-party-applications">
  ## サードパーティアプリケーション向けの強化されたセキュリティ制御
</div>

**非推奨**: 2026年4月23日

**提供終了**: 2026年10月23日

Auth0 では、OAuth 2.1 のベストプラクティスに準拠した、サードパーティアプリケーション向けの強化されたセキュリティ制御を導入します。提供終了日以降、`third_party_security_mode` を指定せずに `POST /api/v2/clients` で新しいサードパーティアプリケーションを作成すると、Auth0 は強化されたセキュリティ制御 (`strict`) を自動的に適用します。この変更の対象となるのは、2026年4月23日より前からサードパーティアプリケーションを使用していたテナントのみで、影響を受けるのも新規作成されるアプリケーションに限られます。既存のサードパーティアプリケーションは、変更しなくてもこれまでどおり引き続き動作します。

強化された制御では、明示的な API 認可、PKCE の必須使用、そして OAuth 2.1 とセキュリティのベストプラクティスに沿った機能に絞った構成が提供されます。

この変更に備えるには、[サードパーティアプリケーション向け強化セキュリティへの移行](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-enhanced-security-third-party-applications) を確認し、対象かどうかを確認したうえで、デフォルトの API 権限を設定し、移行方法を選択してください。

<div id="legacy-management-of-connections-enabled-clients">
  ## 接続で有効なクライアントの従来の管理
</div>

**非推奨**: 2026年1月13日

**提供終了**: 2026年7月13日

Management API の接続オブジェクト内の `enabled_clients` フィールドは、以下のシナリオでは非推奨となります。

* (GET - `/api/v2/connections`) を使用した [複数の接続の取得](https://auth0.com/docs/api/management/v2/connections/get-connections)。
* (GET - `/api/v2/connections/{id}`) を使用した [接続の取得](https://auth0.com/docs/api/management/v2/connections/get-connections-by-id)。
* (PATCH - `/api/v2/connections/{id}`) を使用した [接続の更新](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id)。

この非推奨機能の代替として、2 つの新しい Management API エンドポイントを利用できます。

* [接続で有効なクライアントを取得する](https://auth0.com/docs/api/management/v2/connections/get-connection-clients)。
* [接続で有効なクライアントを更新する](https://auth0.com/docs/api/management/v2/connections/patch-clients)。

この変更に備え、連携が引き続き円滑に機能するよう、影響の有無を確認し、新しいエンドポイントへ移行するために、[有効なクライアント管理を専用の接続エンドポイントへ移行する](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-dedicated-connection-endpoints) を確認してください。

<div id="weak-tls-12-cipher-suites">
  ## 安全性の低い TLS 1.2 暗号スイート
</div>

**非推奨**: 2025年12月10日

**提供終了**: 2026年6月10日

提供終了日以降、Auth0 のサービスエンドポイントおよび Web アプリケーションへの接続では、最新の暗号の使用が必須となります。ネットワーク通信を保護するうえで十分な安全性を提供できなくなった TLS 1.2 暗号スイートのサポートは終了します。具体的には、サポート対象の暗号スイートの変更は以下に適用されます。

* パブリッククラウドおよびプライベートクラウドのテナントのデフォルトドメイン。たとえば、`[tenant_name].eu.auth0.com.`
  * パブリッククラウドおよびプライベートクラウドのテナントのカスタムドメイン。
  * Auth0 Dashboard (`manage.auth0.com`) や Marketplace (`marketplace.auth0.com`) などのサービス関連 Web アプリケーション。
  * Auth0 Content Delivery Network (CDN) 。詳しくは、[Auth0 Public Cloud Service Endpoints](/docs/ja-jp/troubleshoot/customer-support/operational-policies/public-cloud-service-endpoints) をご覧ください。

廃止される暗号スイートの一覧を以下に示します。この一覧には、各暗号を識別する一意の 16 進コードと、その [IANA](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) 名が記載されています。対応する OpenSSL 名については、`ciphersuite.info` へのリンクを参照してください。

削除予定の TLS 1.2 暗号:

* 0xC0, 0x09 - [TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA](https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA/)
  * 0xC0, 0x0A - [TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA](https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA/)
  * 0xC0, 0x23 - [TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256](https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256/)
  * 0xC0, 0x24 - [TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384](https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384/)
  * 0xC0, 0x13 - [TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA](https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA/)
  * 0xC0, 0x14 - [TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA](https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA/)
  * 0xC0, 0x27 - [TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256](https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256/)
  * 0xC0, 0x28 - [TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384](https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384/)
  * 0x00, 0x9C - [TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256](https://ciphersuite.info/cs/TLS_RSA_WITH_AES_128_GCM_SHA256/)
  * 0x00, 0x2F - [TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA](https://ciphersuite.info/cs/TLS_RSA_WITH_AES_128_CBC_SHA/)
  * 0x00, 0x9D - [TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384](https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_GCM_SHA384/)
  * 0x00, 0x35 - [TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA](https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_CBC_SHA/)
  * 0x00, 0x3C - [TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256](https://ciphersuite.info/cs/TLS_RSA_WITH_AES_128_CBC_SHA256/)
  * 0x00, 0x3D - [TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA256](https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_CBC_SHA256/)

<div id="prompt-for-organization-name-without-sso">
  ## SSO なしでの組織名入力の要求
</div>

**非推奨**: 2025年10月31日

**提供終了**: 2026年5月1日

ビジネスユーザーに関連付けられたクライアントアプリケーション (`organization_usage=require`) のコンテキストで開始され、ログインフローの開始時に組織名の入力を求めるよう設定された (`organization_require_behavior=pre_login_prompt`) ログインフローでは、既存の認証済みセッションが考慮されます。

従来は、サービスがユーザーに組織名の入力を求め、その後ユーザーはログインを完了する必要がありました。たとえば、パスワードベースのアカウントを持つユーザーは、選択した組織に対して認証済みセッションが有効であっても、認証情報を再入力する必要がありました。

<div id="unconfirmed-login-with-non-verifiable-callback-uri-redirects">
  ## 検証できないコールバック URI へのリダイレクト時における未確認ログイン
</div>

**非推奨**: 2025年10月28日

**提供終了**: 2026年4月28日

Auth0 では、セキュリティを強化し、アプリケーションのなりすましやフィッシング攻撃のリスクを軽減するため、[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)を使用するすべてのネイティブアプリケーションで、可能な限り [Android App Links](https://developer.android.com/training/app-links#android-app-link) と [Apple Universal Links](https://developer.apple.com/documentation/xcode/allowing-apps-and-websites-to-link-to-your-content) を利用した HTTPS ベースのコールバックへの移行を推奨しています。

さらに Auth0 では、コールバックとしてカスタム URI スキームまたはループバック URI を使用する認証リクエストに対し、新しいログイン確認プロンプトを導入します。このプロンプトは、これまでユーザーの操作なしでレスポンスが返されていた場合に表示されます。

詳細については、[Migrate to Non-Verifiable Callback URI End-User Confirmation](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-to-non-verifiable-callback-uri-end-user-confirmation) を参照してください。

<div id="audience-validation-for-private-key-jwt-authentication">
  ## Private Key JWT認証におけるAudienceの検証
</div>

**非推奨**: 2025年10月6日

**提供終了**: 2025年4月8日

[クライアントアプリケーション認証に使用されるJWTアサーション](/docs/ja-jp/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt)を検証する際、**Auth0では要件がより厳格になり、`aud` (audience) クレームでは、単一のJSON文字列値としてテナントのissuer identifierのみを受け入れるようになります**。

以下のいずれかの方法で`aud`クレームを指定できる仕様は非推奨となっており、サービスは提供終了日以降、これらをサポートしなくなります。

* 文字列のJSON配列。ただし、いずれかの要素に、クライアントの認証先となる該当テナントおよびエンドポイントの有効なissuer identifierまたはエンドポイントURLが含まれている場合に限ります。
* クライアントの認証先となる該当テナントおよびエンドポイントの有効なエンドポイントURLを表す、単一のJSON文字列。

提供終了日に先立ち、アップストリームのアイデンティティプロバイダーに対する認証済みリクエストでPrivate Key JWTを使用するよう構成されたOIDCエンタープライズ接続では、JWTアサーションに含まれる`aud`クレームで、JSON文字列として表された該当のissuer identifierを使用できるようになります。

<div id="extended-attributes-in-azure-active-directory-v1-identity-api-connections">
  ## Azure Active Directory (v1) Identity API 接続の拡張属性
</div>

**非推奨**: 2025年6月18日

**提供終了**: 2025年9月1日

[Azure AD Graph の非推奨化](https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview)と、予定されている[廃止](https://techcommunity.microsoft.com/blog/microsoft-entra-blog/what%E2%80%99s-new-in-microsoft-entra-%E2%80%93-june-2025/4352579#community-4352579-toc-hId--1605859169)に伴い、Auth0 は今後、Azure Active Directory (v1) Identity API を使用するよう構成された Microsoft Azure AD (`strategy=waad`) 接続で、拡張属性関連のオプションを有効にすることをサポートしません。

メールで通知を受け取った場合は、1 つ以上のテナントで、**Azure Active Directory (v1)** Identity API を対象とし、拡張属性を取得するよう構成された Microsoft Azure AD 接続を使用している可能性があり、影響を受けるおそれがあります。

該当するテナントを確認する必要があります。非推奨となった機能に依存している接続については、次のいずれかを行う必要があります。

* 接続の対象を **Microsoft Identity Platform (v2)** に更新し、拡張属性情報の取得時に、非推奨の Azure AD Graph ではなく Microsoft Graph エンドポイントを使用するようにします。

* すべての拡張属性オプションをオフにします。

上記 2 番目の方法でも、拡張情報が不要であれば **Azure Active Directory (v1)** Identity API を対象とする接続を維持できますが、一般的には **Microsoft Identity Platform (v2)** を対象にすることを推奨します。詳しくは、[Connect Your App to Microsoft Azure Active Director](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2) をご覧ください。非推奨化の詳細については、[Auth0 Support](https://support.auth0.com/) までお問い合わせください。

<div id="real-time-webtask-logs-extension">
  ## Real-Time Webtask Logs 拡張機能
</div>

**非推奨**: 2025年6月18日

**提供終了**: 2025年9月16日

Real-Time Webtask Logs 拡張機能は非推奨となっており、2025年9月16日以降に提供終了 (EOL) を迎える予定です。 

代替機能として、[Actions Real-time Logs](/docs/ja-jp/customize/actions/actions-real-time-logs) を Auth0 Dashboard で直接利用できます。この拡張機能は新規インストールできなくなりますが、すでにインストール済みのテナントでは、予定されている EOL まで引き続き利用できます。

<div id="remove-access-to-specific-event-request-properties-in-actions">
  ## Actionsで特定のイベントリクエストプロパティへのアクセスを廃止
</div>

**非推奨**: 2025年6月18日

**提供終了**: 2025年9月16日

Auth0 は、[`post-login`](/docs/ja-jp/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger) および [`credentials-exchange`](/docs/ja-jp/customize/actions/explore-triggers/machine-to-machine-trigger) トリガーで Actions を実行する際に、`event.request.query` と `event.request.body` オブジェクト内の追加のプロパティ名へのアクセスを制限します。制限対象となる予定のリクエストプロパティを参照するために Actions を使用していることが確認されたテナントのみ、**2025年9月16日** まで引き続きアクセスできます。

このサービスでは、リクエスト関連オブジェクト内の次のプロパティ名へのアクセスを制限します。

* `auth_session`
* `authn_response`
* `client_secret`
* `client_assertion`
* `refresh_token`

<div id="multiple-actions-for-custom-phone-and-email-provider-triggers">
  ## カスタム電話プロバイダーおよびメールプロバイダーのトリガーにおける複数のActions
</div>

**非推奨:** 2025年6月16日

**提供終了:** 2025年12月16日

Auth0 では、次のトリガーに関連付けられた Actions について、Action を最大 1 つまでに制限します。

* `custom-phone-provider`
* `custom-email-provider`

この制限は、Management API の [Action を作成](https://auth0.com/docs/api/management/v2/actions/post-action) エンドポイント (`POST` - `/api/v2/actions/actions`) に適用されます。新たに導入されるこの上限が特定のテナントで有効になると、これらのトリガーに対して複数の Action を作成しようとすると失敗します。

<div id="uncustomizable-brute-force-protection-unblock-email-flow">
  ## カスタマイズできない Brute-force Protection のブロック解除メールフロー
</div>

**非推奨:** 2025年6月9日

**提供終了:** 2025年12月9日

[Brute-force Protection](/docs/ja-jp/secure/attack-protection/brute-force-protection) のメールベースのブロック解除フローの更新版では、Universal Login を通じたカスタマイズとローカライズがサポートされ、メールセキュリティスキャナーがブロック解除メールを処理する場合のユーザー体験も改善されています。

<div id="field-fromsandbox-in-authentication-api-error-responses">
  ## Authentication API のエラーレスポンスにおける `fromSandbox` フィールド
</div>

**非推奨:** 2025年6月11日

**提供終了:** 2025年12月11日

カスタムデータベーススクリプトの呼び出しが必要なフローでは、Authentication API のエラーレスポンスで `fromSandbox` フィールドが返されなくなります。たとえば、カスタムデータベース接続のエンドユーザー向けサインアップフローにおける API エラーレスポンスでは、このフィールドは返されなくなります。

<div id="allow-omitting-password-on-smtp-email-provider-host-related-changes">
  ## SMTPメールプロバイダーのホスト関連の変更時にパスワード指定を省略可能にする
</div>

**非推奨:** 2025年5月13日

**提供終了:** 2025年11月13日

[`/api/v2/emails/provider エンドポイント`](https://auth0.com/docs/api/management/v2/emails/patch-provider)に `PATCH` リクエストを使用してSMTPメールプロバイダーのホスト、ポート、またはユーザー名を更新する場合、`credentials.smtp_pass` フィールドにパスワードの指定が必要になることがあります。

SMTPメールプロバイダーの認証情報オブジェクトでは、次のフィールドがサポートされています。

* `credentials.smtp_pass`: SMTPメールプロバイダーのパスワード
* `credentials.smtp_host`: SMTPメールプロバイダーのホスト
* `credentials.smtp_port`: SMTPメールプロバイダーのポート
* `credentials.smtp_user`: SMTPメールプロバイダーのユーザー名

Auth0では、次の場合に `credentials.smtp_pass` フィールドへ明示的に値を指定する必要があります。

* SMTPメールプロバイダーの `credentials.smtp_host`、`credentials.smtp_port`、または `credentials.smtp_user` フィールドを既存の値とは異なる値に更新する場合、またはそれら3つのフィールドの一部だけを更新する場合。

Auth0では、次の場合に `credentials.smtp_pass` フィールドへ明示的に値を指定する必要はありません。

* SMTPメールプロバイダーを更新する際に、リクエスト本文に `credentials.smtp_host`、`credentials.smtp_port`、`credentials.smtp_user` フィールドの既存の値と同じ値が含まれている場合。

<div id="unrestricted-offset-pagination-in-connections-management-api">
  ## Management API の接続における無制限のオフセットページネーション
</div>

**非推奨**: 2025年4月29日

**提供終了**: 2025年10月27日

Management API の [すべての接続を取得する](/docs/ja-jp/api/management/v2/connections/get-connections) エンドポイントで利用できるオフセットベースのページネーションでは、今後、最初の1000件の接続を超えるページ分の結果を取得できなくなります。

たとえば、`page=30&per_page=50` または `page=15&per_page=100` を使用すると、サービスはエラーレスポンスを返します。どちらの場合も、1ページあたりに要求するレコード数に、指定したページインデックスに1を加えた値 (ページインデックスが0始まりであるため) を掛けると、リクエスト対象が最初の1000件の接続を超えるためです。

上記のとおり、ページサイズが50の場合、エラーなしで要求できる最後のページインデックスは19 (`page=19&per_page=50`) です。また、最大ページサイズの100では、ページインデックス9 (`page=9&per_page=100`) まで要求できます。

制限を超える条件では、リクエストに関連付けられたテナントの接続数が1000未満であっても、エラーが返されます。

<div id="nodejs-12-and-16-extensibility-runtimes">
  ## Node.js 12 および 16 の拡張機能ランタイム
</div>

**非推奨**: 2025年2月10日

**提供終了**: 2025年8月15日

Node.js 12 および 16 の拡張機能ランタイムは、Auth0 の各テナントで段階的に利用できなくなります。削除後は、Actions、Rules、Hooks、Custom Database Connections、Custom Social Connections など、すべての拡張機能の連携が Node 22 で実行されるようになります。

Node 22 への移行に関連する技術資料については、[Node 12 および 16 から Node 18 への移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-nodejs-16-to-nodejs-18) および [Node 18 から Node 22 への移行](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations/migrate-nodejs-22) を参照してください。

<div id="new-management-api-scopes-required-for-connection-options">
  ## 接続オプションに必要な新しい Management API スコープ
</div>

**非推奨**: 2024年10月24日

**提供終了**: 2025年7月8日

以下の Management API エンドポイントへのリクエストで `options` フィールドを参照するには、`read:connections_options` スコープが必要になります:

* [接続 > すべての接続を取得](https://auth0.com/docs/api/management/v2/connections/get-connections)
* [接続 > 接続を取得](https://auth0.com/docs/api/management/v2/connections/get-connections-by-id)

以下の Management API エンドポイントへのリクエストで `options` フィールドを変更するには、`update:connections_options` スコープが必要になります:

* [接続 > Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id)

<div id="rules-and-hooks-deprecations">
  ## Rules と Hooks の非推奨化
</div>

**非推奨**: 2023年5月16日

**読み取り専用への移行**: 2024年11月18日

**サポート終了:** 2026年11月18日

2026年11月18日以降、Rules と Hooks は実行されなくなり、削除されます。

2024年11月18日以降も、有効な Rules と Hooks は引き続き実行されますが、読み取り専用モードになります。Auth0 は、Rules と Hooks 機能の削除時期を後日に延期しました。

読み取り専用の Rules と Hooks では、有効化と無効化の切り替えや、それぞれの設定値または secrets の変更は可能です。ただし、Auth0 Dashboard や Management API (Terraform や Auth0 Deploy CLI などの CI/CD ツールを含む) を通じてソースコードを編集することはできません。

読み取り専用への移行までに Actions へ移行できない場合は、tenant の設定変更をデプロイするよう構成された自動 CI/CD フローで、Rules や Hooks に対するサポート対象外の管理操作を実行しないようにしてください。

詳細については、[Rules から Actions への移行](/docs/ja-jp/customize/actions/migrate/migrate-from-rules-to-actions)および [Hooks から Actions への移行](/docs/ja-jp/customize/actions/migrate/migrate-from-hooks-to-actions) を参照してください。

<div id="opt-in-to-wcag-22-aa-compliant-ui-for-universal-login">
  ## Universal Login の WCAG 2.2 AA 準拠 UI を有効にする
</div>

**非推奨:** 2024年8月23日

**End of Life:** 2025年7月31日

Auth0 は、<Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認のため、Auth0 の Authorization Server でホストされる Universal Login にリダイレクトされます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Universal+Login">Universal Login</Tooltip> で従来の非準拠 UI を使用する機能を廃止します。新しい WCAG 準拠バージョンにより、支援技術を利用する方を含むエンドユーザーが、顧客の製品やサービスにアクセスして利用できるようになります。詳細については、[Universal Login のアクセシビリティに関するドキュメント](/docs/ja-jp/authenticate/login/auth0-universal-login)をご覧ください。

<div id="learn-more">
  ## 詳細はこちら
</div>

* [移行プロセス](/docs/ja-jp/troubleshoot/product-lifecycle/migration-process)
* [過去の移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations)