> ## 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.

> すべてのお客様ですでに有効になっているAuth0の更新一覧。

# 過去の移行

以下は、すべてのお客様ですでに有効になっている移行です。ご不明な点がございましたら、[Support Center](https://support.auth0.com/center/s/) からチケットを作成してください。

<div id="protected-properties-in-non-custom-social-connections">
  ## 非カスタムソーシャル接続における保護対象プロパティ
</div>

**非推奨**: 2024年7月30日

**サポート終了**: 2025年1月31日

接続に関するManagement APIエンドポイント (`GET`、`POST`、`PATCH`) では、非カスタムソーシャル接続の`options`オブジェクトにおいて、以下の保護対象プロパティの値を取得または設定できなくなります。

* `authorizationURL`
* `tokenURL`
* `userInfoUrl`
* `baseUrl`
* `userAuthorizationURL`
* `grant_type`
* `authorizationURL`
* `tokenURL`
* `userInfoUrl`
* `baseUrl`
* `userAuthorizationURL`
* `grant_type`

非カスタムソーシャル接続とは、実装ロジックがすべてAuth0サービス内で管理されているソーシャル接続を指します。このカテゴリには、カスタムソーシャルコネクタとして明示的に作成された接続や、カスタムソーシャル接続機能に依存するMarketplaceインテグレーションとして提供される接続は含まれません。

<div id="unwarranted-session-removal-after-management-api-user-updates">
  ## Management API でユーザーを更新した後に意図せずセッションが削除される問題
</div>

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

**サポート終了**: 2025年8月19日

<Tooltip tip="Management API: お客様が管理タスクを実行できるようにする製品。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> の [Update a user](https://auth0.com/docs/api/management/v2/users/patch-users-by-id) エンドポイント (`PATCH /api/v2/users/{id}`) では、データベース接続ユーザーについて、以下の場合にユーザーセッションが無効化されなくなります。

* `email` または `email_verified` 属性が変更されていない値に設定されている場合。
* `email_verified` 属性が `true` に設定されている場合。

<div id="mandatory-use-of-sni-for-https-requests">
  ## HTTPS リクエストにおける SNI の使用必須化
</div>

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

**サポート終了**: 2025年4月29日

Auth0 サービスでは、すべての HTTPS リクエストで [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication) (SNI) の使用が必須となります。SNI は TLS プロトコルの拡張機能で、ハンドシェイク処理の開始時に、接続先のホスト名をクライアントが示せるようにするものです。

作成当初から、当社のプライベートクラウド環境の大半と一部のパブリッククラウド環境では、SNI が必須とされてきました。たとえば、CA-1、JP-1、UK-1 のパブリッククラウド環境では、常に SNI が必要でした。

この変更により、SNI の必須要件は残りの環境にも適用されます。環境ごとのスケジュールの詳細については、[End-of-Life Rollout for Mandatory Use of SNI for HTTPS Requests](https://support.auth0.com/center/s/article/End-of-Life-Rollout-for-Mandatory-Use-of-SNI-for-HTTPS-Requests) の記事を参照してください。

<div id="always-use-https-for-communication-with-auth0">
  ## Auth0 との通信には常に HTTPS を使用してください
</div>

**非推奨**: 2024年9月4日

**サポート終了**: 2024年10月4日

2024年10月4日以降、Auth0 では、暗号化されていない HTTP を使用する API リクエストが安全な HTTPS に自動的にリダイレクトされなくなり、エラーが返されるようになります。サービスの中断を避けるため、使用中または公開中の HTTP URL はすべて HTTPS を使用するよう更新してください。

<div id="management-api-transition-updating-roles-assignment-to-require-create-scope">
  ## Management API の移行: ロール割り当てに `create:role_members` スコープ が必要になります
</div>

**非推奨**: 2024年3月7日

**サポート終了**: 2024年9月10日

User-Roles endpoint (`POST /api/v2/users/{id}/roles`) 用の Management API scopes には、`create:role_members` スコープ が必要になります。これにより、その スコープ が意図する permissions をより適切に反映できるようになります。

これまでは、`read:roles` スコープ でユーザーにロールを割り当てることができました。

<div id="update-applications-that-use-cross-origin-authentication">
  ## クロスオリジン認証を使用するアプリケーションを更新する
</div>

**非推奨**: 2024年4月25日

**サポート終了**: 2024年10月10日

Auth0 で新規作成されるアプリケーションでは、クロスオリジン認証はデフォルトで無効になります。一部の Management API エンドポイント ([Get Clients](https://auth0.com/docs/api/management/v2/clients/get-clients), [Get Client by ID](https://auth0.com/docs/api/management/v2/clients/get-clients-by-id)) の呼び出しは、`cross_origin_authentication` を使用するように変更する必要があります。

<div id="remove-subscription-tickets-access-for-tenant-admins">
  ## テナント管理者による Subscription Tickets へのアクセスの廃止
</div>

**非推奨**: 2024年6月5日

**サポート終了**: 2024年8月5日

Auth0 Support Center 内で [Subscription Tickets](/docs/ja-jp/troubleshoot/customer-support/open-and-manage-support-tickets) を閲覧するためのアクセス権が、2024年8月5日に変更されます。テナント内のすべてのユーザーが作成したすべてのサポートチケットの閲覧と管理を引き続き行うには、新しい Elevated Support Access ロールが必要です。

<div id="password-reset-and-email-verification-links-in-tenant-logs-deprecation">
  ## テナントログ内のパスワードリセットリンクおよびメール確認リンクの非推奨化
</div>

**非推奨**: 2023年12月7日

**サポート終了**: 2024年2月5日

今後、パスワードリセットリンクおよびメール確認リンクはテナントログに記録されなくなります。これらのリンクは、パスワードリセットまたはメール確認の<Tooltip tip="Management API: お客様が管理タスクを実行できるようにする製品です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip>リクエストのレスポンスから取得できます。

<div id="reducing-maximum-expiration-time-for-login-transactions">
  ## ログイン トランザクションの最大有効期限の短縮
</div>

**非推奨**: 2023年9月5日 (Public Cloud) 、2023年11月21日 (Private Cloud)

**サポート終了**: 2024年2月21日

この変更により、リダイレクトベースのログイン フローの有効期間は最大1時間に制限されます。完了までに1時間を超えるログイン フローは、Universal Login と Classic Login の両方で期限切れになります。期限切れ後にエンドユーザーのブラウザーから後続の操作 (例: メールアドレス/パスワードの入力、Actions/Rules へのリダイレクトバックなど) を行うと、次のいずれかになります。

* フローを新しいログイン トランザクションとして再開するため、関連付けられたアプリケーションの既定のログイン ルートにリダイレクトされる、または
* 既定のログイン ルートが設定されていない場合は、エラー ページが表示される。

<div id="unregistered-scopes-in-refresh-tokens-deprecation">
  ## リフレッシュトークンにおける未登録スコープの廃止
</div>

**非推奨**: 2023年7月12日

**サポート終了**: 2024年1月17日

未登録のスコープをリクエストできないようにするため、<Tooltip tip="リフレッシュトークン: ユーザーに再度ログインさせることなく、新しい Access Token を取得するために使用されるトークン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=refresh+token">リフレッシュトークン</Tooltip>の交換時におけるスコープ評価を改善します。`aud` または `audience` の値 (テナント内に登録された API のもの) に対して登録されていないカスタムスコープ値は、未登録スコープと見なされます。

この変更により、API のスコープ評価には、ユーザー認証時にリクエストされたカスタムスコープや、[Rules](/docs/ja-jp/customize/rules) などの拡張機能を通じて追加されたカスタムスコープも含まれるようになります。この評価では、すべてのスコープが登録済みであることを検証し、未登録のものがある場合はエラーを返します。

<div id="auth0-cordova-angular-auth0-and-express-oauth2-bearer-repo-deprecations">
  ## auth0-cordova、angular-auth0、および express-oauth2-bearer リポジトリの非推奨化
</div>

**非推奨**: 2023年4月27日

**サポート終了**: 2023年6月30日 (express-oauth2-bearer) 、2023年10月27日 (angular-auth0 および auth0-cordova)

以下のリポジトリは非推奨となりました。

* [express-oauth2-bearer](https://github.com/auth0/express-oauth2-bearer) | [移行ガイド](https://github.com/auth0/express-oauth2-bearer/blob/master/MIGRATION_GUIDE.md)
* [angular-auth0](https://github.com/auth0/angular-auth0) | [移行ガイド](https://github.com/auth0/angular-auth0/blob/master/MIGRATION_GUIDE.md)
* [auth0-cordova](https://github.com/auth0/auth0-cordova) | [移行ガイド](https://github.com/auth0/auth0-cordova/blob/master/MIGRATION_GUIDE.md)

これらのライブラリは今後サポートされません。該当する日付までに、現在運用中のすべてのプロジェクトからこれらのライブラリを削除してください。

ご質問やご不明な点がある場合は、GitHub からお問い合わせください。

<div id="actions-migration-from-nodejs-16-to-nodejs-18">
  ## Actions の Node.js 16 から Node.js 18 への移行
</div>

**移行期限**: 2023年9月11日

Actions を通じて今後のすべての LTS 版 Node.js をサポートし、Node.js 開発者コミュニティとの足並みをそろえる取り組みの一環として、Node 16 がまだ Active LTS である間に Node 18 をリリースします。すべてのお客様に、今すぐ Node 18 へ移行し、LTS のメリットを最大限に活用されることを強くお勧めします。Node 16 LTS は 9 月まで引き続き利用できますが、LTS 終了後も使い続けることには一定のリスクが伴う可能性があるため、Node 18 へのアップデートをお勧めします。

Node.js 18 は現在、当社の拡張機能スイート全体で一般提供 (GA) されています。これには、Actions、Rules、Hooks、Database Scripts、Custom Social Connections が含まれます。コード セキュリティのベストプラクティスに従うため、2023年9月11日までに Node 18 へアップデートすることを強くお勧めします。

<div id="support-for-edgejs-in-extensibility-features">
  ## Extensibility 機能における edge.js のサポート
</div>

**非推奨:** 2022年12月21日

**サポート終了:** 2023年6月21日

2023年6月21日以降、Auth0 は Extensibility 機能において Node.js から .NET および C# を実行する機能のサポートを終了します。Auth0 はこれまで、edge.js という Node.js モジュールを通じて、Rules、Hooks、Custom Database Scripts の拡張コードを記述するために、C# 言語の一部をサポートしてきました。

Extensibility 機能で Node.js から .NET および C# を実行するサポートを非推奨とすることは、信頼できないコードを実行するための高性能かつ安全なプラットフォームを維持するうえで重要です。この変更により、次世代の Extensibility 機能を継続的に改善できるようになります。
詳しくは、[edge.js extensibility features からの移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-from-edge-js-extensibility-features)をご覧ください。

<div id="support-for-oracledb-in-extensibility-features">
  ## Extensibility 機能 での oracledb のサポート
</div>

**非推奨:** 2022年12月21日

**サポート終了:** 2023年6月21日

Auth0 は、2023年7月31日以降、SharePoint 2010/2013 向け auth0-claims-provider アドオンのサポートを終了します。

2023年6月21日以降、Auth0 は Extensibility 機能での Node.js から Oracle Database への接続をサポートしなくなります。これまで Auth0 は、[oracledb](https://www.npmjs.com/package/oracledb) という Node.js モジュールを使用して、Rules、Hooks、Custom Database Scripts の extensibility コードから Oracle Database に接続できるようサポートしてきました。

Extensibility における Node.js から Oracle Database への接続サポートの廃止は、信頼できないコードを実行するための高性能で安全なプラットフォームを維持するうえで重要です。この変更により、次世代の Extensibility 機能を今後も継続的に改善していくことができます。

詳細については、[oracledb extensibility features からの移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-from-oracledb-extensibility-features) をご覧ください。

<div id="auth0-claims-provider-for-sharepoint-2010-2013">
  ## Auth0 Claims Provider for SharePoint 2010 / 2013
</div>

**非推奨:** 2023年1月31日

**サポート終了:** 2023年7月31日

Auth0 は、2023年7月31日をもって、SharePoint 2010/2013 向け auth0-claims-provider アドオンのサポートを終了します。このアドオンがないと、SharePoint 2010/2013 のユーザーに権限を割り当てるために、Auth0 接続で「SharePoint People Picker」を使用できなくなります。

2023年7月31日までに、auth0-claims-provider アドオンとの連携をすべて削除する必要があります。その日以降、auth0-claims-provider アドオンとの既存の連携は正常に機能しなくなり、アプリケーションのユーザーに影響が及ぶ可能性があります。

<div id="checkpoint-pagination-on-get-role-users-endpoint">
  ## Get Role Users エンドポイントのチェックポイント ページネーション
</div>

**非推奨:** 2022年11月9日

**サポート終了:** 2023年5月9日

パフォーマンス向上のため、Get Role Users Management API エンドポイントで合計1,000件を超える結果を返すには、チェックポイント ページネーション方式を使用する必要があります。このページネーション方式は、大量の結果を扱えるよう最適化されています。オフセット ページネーション方式で取得できる結果は、1,000件までに制限されます。

2つのページネーション方式の実装の詳細については、[Get Role Users エンドポイントの Management API ドキュメント](https://auth0.com/docs/api/management/v2/roles/get-role-user)を参照してください。

<div id="legacy-custom-claims">
  ## レガシー カスタムクレーム
</div>

**非推奨:** 2022年7月28日 (Public Cloud) 、2022年8月31日 (Private Cloud)

**サポート終了:** 2023年1月30日 (Public Cloud) 、2023年4月18日 (Private Cloud)

Auth0 は、Public Cloud では 2023年1月30日から、Private Cloud では 2023年4月18日から、Auth0 Actions および Authentication API の `/userinfo` エンドポイントのレスポンスで、<Tooltip tip="JSON Web Token (JWT): 2者間でクレームを安全に表現するために使われる標準の ID Token 形式（多くの場合 Access Token 形式でもあります）。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=JWT">JWT</Tooltip> トークンに名前空間のないカスタムクレームを追加できるようになります。これまで Auth0 では、拡張コード ([Rules](/docs/ja-jp/customize/rules) / [Hooks](/docs/ja-jp/customize/hooks) / [Actions](/docs/ja-jp/customize/actions)) を通じて、アクセストークンおよび <Tooltip tip="ID Token: リソースへのアクセスではなく、クライアント自身のための資格情報です。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=ID+tokens">ID tokens</Tooltip> に名前空間付きクレームを追加できました。カスタムクレームへの移行により、非公開の名前空間のないカスタムクレームと OIDC ユーザープロファイルクレームを<Tooltip tip="Access Token: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可資格情報です。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=access+tokens">access tokens</Tooltip>に追加できるようになります。ID tokens は現在ユーザープロファイルクレームをサポートしており、今後は非公開の名前空間のないカスタムクレームもサポートするようになります。これらのクレームは Auth0 の `/userinfo` レスポンスにも追加されます。移行を開始するには、[Custom Claims Migration Guide](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/custom-claims-migration) をご覧ください。

テナントで、これまでこの非推奨化により無視されていた名前空間のないカスタムクレームを設定しようとする拡張コード ([Rules](/docs/ja-jp/customize/rules) / [Hooks](/docs/ja-jp/customize/hooks) / [Actions](/docs/ja-jp/customize/actions)) を実行している場合、それらのクレームがトークンおよび `/userinfo` レスポンスに含まれるようになります。設定と Auth0 のログを確認することをお勧めします。

名前空間のない非公開クレームの追加に伴い、Auth0 はテナントに影響する可能性がある以下の制限を適用します。

* Auth0 は、カスタムクレームのペイロードを最大 100KB に制限します。
* Auth0 は、<Tooltip tip="OpenID: アプリケーションがログイン情報を収集・保存することなく、ユーザーの本人確認を行えるようにする認証のオープン標準です。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=OPENID">OPENID</Tooltip> 標準クレーム、または Auth0 が内部で使用するクレームのカスタマイズや変更を制限します。
* 今後、Auth0 は上記一覧に含まれていない他のクレームの使用を制限する可能性があります。その場合は、移行のための十分な期間を設けたうえでお客様に通知します。
* Auth0 は、`/userinfo` エンドポイントを除き、Auth0 の <Tooltip tip="Audience: 発行されたトークンの対象者を一意に識別する子です。トークン内では aud という名前で、その値には ID Token の場合はアプリケーション（Client ID）、Access Token の場合は API（API Identifier）の ID が含まれます。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=audience">audience</Tooltip> を持つアクセストークンで、非公開の名前空間のないカスタムクレームを作成することを制限します。
* アクセストークンに追加できるのは、指定された OIDC ユーザープロファイルクレームのみです。
* Auth0 は、\$ 文字で始まるカスタムクレームの作成を制限します。

カスタムクレームの詳細については、[Create Custom Claims](/docs/ja-jp/secure/tokens/json-web-tokens/create-custom-claims) をご覧ください。

<div id="legacy-private-cloud-platform">
  ## 旧 Private Cloud プラットフォーム
</div>

**非推奨:** 2022年6月13日

**サポート終了:** 2023年1月31日

Auth0 Private Cloud を支える基盤インフラストラクチャの改善の一環として、最新の Kubernetes ベースの技術スタックの導入とデータベースのアップグレードを進めています。現在、すべての Auth0 Private Cloud のお客様と連携し、今年中に各プライベートクラウド環境を新しいインフラストラクチャスタックへアップグレードできるよう、日程を調整しています。これに伴い、旧スタックは 2023年1月31日をもって廃止されます。

また、2205 (2022年5月リリース) は、旧 Private Cloud プラットフォーム向けの最後の正式リリースです。バグやセキュリティ脆弱性については、必要に応じて評価し、パッチリリースで対応します。新しいインフラストラクチャスタックへのアップグレードに先立ち、各環境をアップグレードに対応可能な最小互換バージョンまで更新する必要があります。

ご不明な点がございましたら、担当の Technical Account Manager までお問い合わせください。

<div id="log-extensions">
  ## ログ拡張機能
</div>

**非推奨:** 2022年5月4日 (Public Cloud) 、2022年6月9日 (Private Cloud リリース 2205)

**サポート終了:** 2023年5月2日 (Public Cloud) 、2023年1月6日 (Private Cloud)

Public Cloud では2022年5月4日から、Private Cloud では2022年6月9日から、以下の Auth0 ログ拡張機能が非推奨となります。

* Auth0 Authentication API Webhooks
* Auth0 Management API Webhooks
* Cloudwatch へのログ
* Logentries へのログ
* Loggly へのログ
* Logstash へのログ
* Papertrail へのログ
* Splunk へのログ
* Sumo Logic へのログ

**非推奨:** 2022年11月2日 (Public Cloud) 、2022年12月21日 (Private Cloud)

**サポート終了:** 2023年5月2日 (Public Cloud) 、2023年5月31日 (Private Cloud)

Public Cloud では2022年11月2日から、Private Cloud では2022年12月21日から、以下の Auth0 ログ拡張機能が非推奨となります。

* Segment へのログ
* Mixpanel へのログ
* AppInsights へのログ
* Azure Blob Storage へのログ

上記のログ拡張機能はすべて現在、非推奨となっています。[Auth0 Marketplace](https://marketplace.auth0.com/) のログイベントストリームまたはインテグレーションを利用することで、同等の機能を設定できます。Public Cloud では2022年11月2日、Private Cloud では2022年12月21日をもって、Auth0 は上記一覧にあるインストール済みのログ拡張機能のサポートを終了します。詳細については、[Migrate from Log Extensions](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-from-log-extensions) を参照してください。

<div id="tenant-hostname-validation">
  ## テナントのホスト名の検証
</div>

**非推奨**: 2021年12月9日および2021年12月 (Private Cloud リリース 2112.2)

**サポート終了**: 2022年6月9日および2022年9月9日 (Private Cloud)

Public Cloud では2022年6月9日以降、Private Cloud では2022年9月9日以降、Auth0 は Authentication API の識別プロセスにテナントのホスト名を検証する手順を追加し、API 呼び出しのセキュリティを強化します。呼び出しが行われると、Authentication API はリクエスト元テナントのエンティティ識別子 (例: `client_id`) と、URL ドメイン内のテナント名の両方を検証します。識別子を所有するテナントは、URL ドメイン内のテナントと同一で**なければならず**、一致しない場合はリクエストが拒否されます。

アプリケーションまたは API が以下のエンドポイントのいずれかを呼び出す場合は、リクエスト元テナントの識別子とホスト名が一致するように API 呼び出しを設定する必要があります。

* `/oauth/token`
* `/co/authenticate`
* `/userinfo`
* `/login`
* `/oauth/revoke`
* `/mfa/challenge`
* `/p/<connection-type>/<ticket>` (Enterprise 接続プロビジョニング エンドポイント)

詳しくは、[Tenant Hostname Validation Migration](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/tenant-hostname-migration) をご覧ください。

<div id="nodejs-16-migration">
  ## Node.js 16 への移行
</div>

**サポート終了**: 2022年4月30日

2022年4月30日をもって、[Node.js v12 の長期サポート (LTS) が終了しました](https://github.com/nodejs/Release#release-schedule)。これは、Node.js 開発チームがこのバージョンに対する重大なセキュリティ修正をバックポートしなくなったことを意味します。そのため、拡張機能コードがセキュリティ脆弱性にさらされるおそれがあります。そこで、Auth0 は Node 12 から Node 16 への移行を進めています。

Node 16 への更新によって Node.js 標準ライブラリに破壊的変更が加わることはありませんが (Rules と Custom Database Action Scripts は影響を受けます。詳しくは [Breaking changes - Rules and Custom Database Action Scripts only](#breaking-changes-rules-only) のセクションを参照してください) 、セキュリティおよびコンプライアンスの観点から、Node バージョン 12 をご利用のお客様には、Active Long-Term Support (LTS) の Node バージョンを継続してご利用いただくことを推奨します。現在も Node 8 を使用しているお客様は、セキュリティコンプライアンスの要件を満たしておらず、セキュリティリスクを解消するために Node 16 へ移行する必要があります。Public Cloud テナントでは 2022年2月22日に Node 8 ランタイムを削除し、Private Cloud では 2022年4月のリリースで削除しました。これらの日付以降も Node 8 に設定されたままのテナントでは、サービスが中断するリスクがあります。

<div id="opaque-access-token-and-authorization-code-fixed-length">
  ## Opaque Access Token と認可コードの固定長
</div>

**非推奨**: 2021年10月7日 (Public Cloud) 、2021年12月 (Private Cloud)

**サポート終了**: 2022年4月12日 (Public Cloud) 、2022年6月30日 (Private Cloud)

Public Cloud では2022年4月12日から、Private Cloud では2021年12月版以降、クライアントが認可コードや Access Token の値について前提を置かないようにするため、また [OAuth specification RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) に準拠するため、Access Token と認可コードは可変長で発行されます。現在、Access Token と認可コードの長さは固定です。現在の認可コードの長さは、一部のセキュリティ専門家の推奨よりも短くなっています。この変更により、Auth0 はより強固なコードとトークンを提供すると同時に、Auth0 システムのパフォーマンスも向上させます。

特定の長さの認可コードおよび Access Token に依存するよう構成されたシステムをご利用のお客様は、Public Cloud では2022年4月12日までに、Private Cloud では2022年6月30日のリリースまでに、固定長の構成から可変長の構成へ変更する必要があります。

<div id="nodejs-v8-extensibility-runtime-end-of-life">
  ## Node.js v8 拡張ランタイムのサポート終了
</div>

**非推奨**: 2020年4月15日

**サポート終了**: 2022年2月25日 (Public Cloud) 、2022年4月 (Private Cloud リリース)

2019年12月13日をもって、[Node.js v8 は長期サポート (LTS) の対象外となりました](https://github.com/nodejs/Release#release-schedule)。これは、このバージョンに対して重大なセキュリティ修正がバックポートされなくなったことを意味します。現在も Node 8 を使用しているお客様は、セキュリティ要件を満たしておらず、セキュリティリスクを解消するには Node 12 へ移行する必要があります。テナントレベルの Node バージョンを 8 から 12 に移行する方法の詳細については、[Node.js 8 から Node.js 12 への移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-to-nodejs-12)をご覧ください。

また、Node.js v12 も 2022 年に LTS を終了するため、Rules と Hooks を使用しているすべてのお客様には、できるだけ早く、また 2022 年 4 月 30 日に Node.js コミュニティによる Node 12 のサポートが正式に終了する前に、Node 16 を使用する Actions へ移行することを強くお勧めします。必要な移行手順の詳細については、[Rules と Hooks から Actions への移行](/docs/ja-jp/customize/actions/migrate/migrate-from-rules-to-actions)をご覧ください。

<div id="legacy-network-edge-deprecation">
  ## Legacy Network Edge の非推奨
</div>

**非推奨**: 2021年5月5日 (Public Cloud)

**サポート終了**: 2021年11月3日 (Public Cloud)

Auth0 の従来のネットワークエッジは、Public Cloud で機能しなくなります。2021年11月3日以降、新しい Auth0 ネットワークエッジへの移行を完了していない Public Cloud テナントには、トラフィックが送られなくなります。新しい <Tooltip tip="カスタムドメイン: 固有の名前（バニティ名）を使用するサードパーティのドメイン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=custom+domains">カスタムドメイン</Tooltip> はすべて、自動的に新しいネットワークエッジ上に作成されます。

<div id="unpaginated-management-api-v2-request-deprecation">
  ## ページネーションされていない Management API v2 リクエストの非推奨化
</div>

**非推奨**: 2020年7月21日 (Public Cloud)

**サポート終了**: 2021年1月26日 (Public Cloud) 、2022年2月 (Private Cloud リリース)

2021年1月26日以降、以下の Management API v2 エンドポイントへのリクエストは、Public Cloud テナントでは最大50件までしか返されなくなります。50件を超える項目を取得するには、`page` と `per_page` パラメーターを指定する必要があります。2020年7月21日以降、Auth0 はこの変更に備えられるよう、テナントのログと移行用トグルを表示します。

* [`GET /api/v2/clients`](https://auth0.com/docs/api/management/v2#!/Clients/get_clients)
* [`GET /api/v2/client-grants`](https://auth0.com/docs/api/management/v2#!/Clients/client_grants)
* [`GET /api/v2/grants`](https://auth0.com/docs/api/management/v2#!/Clients/grants)
* [`GET /api/v2/connections`](https://auth0.com/docs/api/management/v2#!/Clients/connections)
* [`GET /api/v2/device-crecentials`](https://auth0.com/docs/api/management/v2#!/Clients/device_credentials) (`type` クエリ パラメーターを使用する場合)
* [`GET /api/v2/resource-servers`](https://auth0.com/docs/api/management/v2#!/Clients/resource_servers)
* [`GET /api/v2/rules`](https://auth0.com/docs/api/management/v2#!/Clients/rules)

影響を受けるのは、2020年7月21日より前に作成され、かつ、複数の結果を返す可能性があるクエリで `per_page` パラメーターを指定せずに、対象のエンドポイントを継続的に呼び出しているすべての Public Cloud テナントです。一方、2020年7月21日以降に作成されたテナント、対象のエンドポイントを使用していないテナント、対象のエンドポイントを使用していて `per_page` パラメーターを指定しているテナント、または常に1件の結果しか返さないクエリを実行しているテナントは影響を受けません。詳しくは、[Management API v2 エンドポイントのページネーション付きクエリへの移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-to-paginated-queries)をご覧ください。

<div id="private-cloud-custom-domain-deprecation">
  ## Private Cloud カスタムドメインの廃止
</div>

**非推奨**: 2021年6月17日

**サポート終了**: 2021年12月20日

すべての Auth0 デプロイ環境で一貫性を保ち、Auth0 の Custom Domain 機能の強化に注力するため、2021年12月20日をもって Private Cloud Custom Domain 機能の提供を終了します。一貫性を確保することで、機能強化や信頼性に関する問題への対応をより迅速に進められるようになり、運用効率の向上と、お客様によるカスタムドメイン活用の早期化につながります。

<div id="logout-redirect-validation">
  ## ログアウト リダイレクトの検証
</div>

**非推奨**: 2021年5月25日

**サポート終了日**: 2021年12月1日

2021年12月1日以降、ログアウト時の動作が変更され、ログアウトの実行中に <Tooltip tip="Identity Provider (IdP): デジタルアイデンティティを保存および管理するサービス。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Identity+Providers">Identity Providers</Tooltip> から `/login/callback` に渡される `returnTo` クエリパラメーターは使用されなくなり、代わりに Auth0 のログアウト API に渡された URI に常にユーザーがリダイレクトされるようになります。Auth0 にこれらの API のいずれかが事前に呼び出された記録がない場合、ログアウト自体は完了しますが、リダイレクトは行われず、エンドユーザーにはエラーページが表示されます。詳細については、[Logout Redirects Migration Guide](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations/logout-return-to) をご覧ください。

<div id="application-admin-dashboard-role-deprecation">
  ## Application Admin Dashboard ロールの廃止
</div>

**非推奨**: 2021年2月1日

**サポート終了**: 2021年9月30日 (Public Cloud) 、2021年9月 (Private Cloud monthly release)

Auth0 では、Dashboard のロールベースアクセス制御が変更されます。現在定義されている Application Administrator ロールは廃止予定です。2021年2月1日以降、管理者は廃止予定の Application Administrator ロールでメンバーを招待できなくなります。既存のアプリケーション固有の管理者は、提供終了日までは現在の権限セットのまま Dashboard を引き続き利用できます。

チームメンバー間のコラボレーションをより安全かつ効率的に行えるよう、アクセスが制限された viewer ロールや editor ロールを含む、新しい Dashboard ロール群が利用可能になっています。editor ロールがサポートされているサブスクリプションプランでは、新しい **Editor - Specific Apps** ロールが従来の **Application Administrator** ロールに置き換わります。

次の条件に当てはまる場合、お使いのテナントはこの廃止の影響を受けます。

* 2021年2月1日より前に作成されている
* **Application Admin** ロールを持つテナントメンバーが少なくとも1人いる
* Dashboard ロール機能のプレビューにオプトインしていない

2021年2月1日以降、Auth0 はこの変更への準備に役立つよう、移行用のトグルを表示します。詳しくは、[Migrate to Manage Dashboard New Roles](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-tenant-member-roles) を参照してください。

<div id="legacy-tls-deprecation">
  ## レガシー TLS の廃止
</div>

**非推奨**: 2021年1月19日

**サポート終了**: 2021年5月10日 (Public Cloud) 、2021年6月の Private Cloud リリース (v2106)

Public Cloud では2021年5月10日以降、また Private Cloud では2021年6月のリリース (v2106) 以降、Auth0 のネットワークエッジで TLS 1.0 または TLS 1.1 のトラフィックは受け付けられなくなります。これらのレガシープロトコルは安全ではなく、業界で広く知られている脆弱性や弱点があります。最大限のセキュリティを確保するため、すべての Auth0 クライアントは TLS 1.2 以降にアップグレードする必要があります。必要な詳細や手順は、アプリケーションによって異なります。

<div id="auth0-analyticsjs-deprecation">
  ## Auth0-analytics.js の非推奨化
</div>

**非推奨**: 2018年1月

**サポート終了**: 2021年1月

Auth0 は、Lock に Facebook と Google Analytics の連携を追加する [auth0-analytics.js library](https://github.com/auth0/auth0-analytics.js/) の使用を非推奨としました。このライブラリは Lock のイベントを監視し、それらを Auth0-tag-manager.js ライブラリに渡します。従来の環境では、一部のケースで引き続き動作する可能性があります。このライブラリは現在メンテナンスされていません。Facebook、X、Google などのサードパーティ分析ライブラリへのプロキシリクエストを管理するために、[auth0-tag-manage.js](https://github.com/auth0/auth0-tag-manager) を使用するカスタムコードの作成が必要になる場合があります。

<div id="device-credential-metadata-without-user_id-deprecation">
  ## `user_id` なしのデバイス認証情報メタデータの廃止
</div>

**非推奨**: 2020年8月31日

**サポート終了**: 2020年12月17日

Auth0 では現在、[GET /api/v2/device-credentials エンドポイント](https://auth0.com/docs/api/management/v2/#!/Device_Credentials/get_device_credentials) を使用する際に `user_id` の指定が必須となっています。リクエストに `user_id` が含まれていない場合は、400 ステータスコードが返されます。この廃止の影響を受けるかどうかは、テナントのログにある `depnote` を確認してください。

Auth0 は、この廃止の影響を受けるテナントを特定し、それらのテナントの管理者に連絡しました。現在お使いのテナントで `user_id` なしのリクエストを送信している場合は、できるだけ早く対応してください。

<div id="azure-adadfs-email-verification-deprecation">
  ## Azure AD/ADFS のメール検証の廃止
</div>

**非推奨**:

* Public Cloud: 2020年11月18日
* Private Cloud: 2020年12月1日

**サポート終了**:

* Public Cloud: 2021年5月18日
* Private Cloud: 2021年6月の Private Cloud リリース (v2106)

Auth0 はこれまで、Azure AD および ADFS 接続で `email_verified` フィールドを true に設定していました。この廃止日より前に Azure AD/ADFS 接続を使用していた場合は、メール検証の接続設定を上書きして従来の動作を維持するテナント設定が適用されています。

Public Cloud では 2021年5月18日から、Private Cloud では 2021年6月の Private Cloud リリース (v2106) から、Auth0 はすべての Azure AD/ADFS 接続で接続レベルのプロパティを使用するようになります。それまでに、すべての接続が適切に設定されていることを確認してください。詳細については、[Email Verification for Azure AD and ADFS](/docs/ja-jp/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification) を参照してください。

<div id="samesite-cookie-attribute-changes">
  ## sameSite Cookie 属性の変更
</div>

**適用開始**: 2020年2月

Google Chrome v80 では、Cookie の処理方法が変更されます。これに伴い、Auth0 でも Cookie の取り扱いに関して以下の変更を実施します。

* `samesite` 属性が設定されていない Cookie は、`lax` として設定されます
* `sameSite=none` が設定された Cookie はセキュアである必要があり、そうでない場合はブラウザーの Cookie jar に保存できません

これらの変更は、セキュリティを向上させ、CSRF 攻撃の緩和に役立てることを目的としています。詳細については、[sameSite Cookie 属性の変更](/docs/ja-jp/manage-users/cookies/samesite-cookie-attribute-changes) を参照してください。

<div id="user-search-v2-deprecation">
  ## User Search v2 の廃止
</div>

**非推奨**: 2018年11月10日

**サポート終了**: 2019年6月30日 (Public Cloud) 、2021年5月 (Private Cloud 月次リリース)

Public Cloud では、User Search v2 は非推奨となっており、2019年6月30日までに対応を完了している必要がありました。この移行を完了する必要があるお客様には通知を送付しました。

Private Cloud では、User Search v1 および v2 のエンドポイントは 5月の Private Cloud 月次リリース以降利用できなくなり、新しい User Search v3 エンドポイントに置き換えられました。

<div id="passwordless-endpoint-from-confidential-applications-deprecation">
  ## Confidential Applications からの Passwordless エンドポイントの廃止
</div>

Auth0 は、呼び出しがそのアプリケーションに代わって行われていることを Auth0 が確認できない場合、confidential applications からの `/passwordless/start` エンドポイントの使用を廃止しました。詳しくは、[Migrate to Passwordless Endpoint from Confidential Applications](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-to-passwordless) をご覧ください。<Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認のために、Auth0 の Authorization Server でホストされている Universal Login にリダイレクトされます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Universal+Login">Universal Login</Tooltip> のクリックジャッキング対策の変更

クリックジャッキングを防ぐため、ログインページを iframe で表示する場合に備えて、Auth0 はヘッダーを追加するためのオプトイン設定を導入しました。これを有効にすることを強く推奨します。詳細は、[Clickjacking Protection for Universal Login Change](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/clickjacking-protection-for-universal-login) をご覧ください。

<div id="management-api-endpoints-using-id-token-credentials-deprecation">
  ## ID token認証情報を使用するManagement APIエンドポイントの非推奨化
</div>

**非推奨**: 2018年3月31日

**サポート終了**: 未定

Auth0では、一部のusersおよびdeviceエンドポイントの呼び出しにID tokenを認証情報として使用する方法が非推奨となり、代わりにaccess tokenを使用する方式に移行しています。詳細については、[Migrate to Management API Endpoints with Access Tokens](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-to-calling-api-with-access-tokens)および[Migrate to Link User Accounts with Access Tokens](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration)を参照してください。

<div id="resource-owner-password-oauthro-deprecation">
  ## Resource Owner Password /oauth/ro の非推奨化
</div>

**非推奨化**: 2017年7月08日

**提供終了**: TBD

2017年7月08日をもって、Auth0 はパスワード接続および <Tooltip tip="Passwordless: パスワードを第一要素として使用しない認証方式。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=passwordless">パスワードレス</Tooltip> 接続の両方で、`/oauth/ro` エンドポイントを非推奨としました。現在は、`/oauth/token` エンドポイントを使用して同じ機能を実装できます。詳しくは、[Resource Owner Password Flow Migration](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migration-oauthro-oauthtoken) をご覧ください。

<div id="management-api-v1-deprecation">
  ## Management API v1 の非推奨化
</div>

**非推奨化**: 2016年10月

**提供終了**:

* Public Cloud: 2020年7月13日
* Private Cloud: 2020年11月の月次リリース

Management API v1 は、Public Cloud では 2020年7月13日に提供終了となります。Private Cloud では 2020年11月の月次リリースまで Management API v1 が含まれますが、このリリースが Management API v1 を含む最後のリリースとなります。サービスの中断を防ぐため、それまでに対応が必要になる場合があります。この移行を完了する必要があるお客様には、これまでも通知をお送りしており、今後も継続してお送りします。

<div id="instagram-connection-deprecation">
  ## Instagram 接続の廃止
</div>

**非推奨**: 2020年3月5日

**提供終了**: 2020年3月31日

Facebook は、2020年3月31日をもって Instagram のレガシー API を停止し、Instagram ログインを実装するための代替手段は提供しないと発表しました。詳細については、[Instagram Connection Deprecation](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/instagram-connection-deprecation) を参照してください。

<div id="yahoo-api-changes">
  ## Yahoo API の変更
</div>

**非推奨**: 2020年3月1日

**提供終了**: 2020年3月1日

Yahoo は、ユーザープロファイルの取得方法と、そこに含まれる情報を変更しました。詳細については、[Yahoo API の変更](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/yahoo-api-changes) を参照してください。

<div id="google-cloud-messaging-deprecation">
  ## Google Cloud Messaging の廃止
</div>

**非推奨化**: 2019年4月11日

**提供終了**: 2019年4月11日

2019年4月11日をもって、[Google は Google Cloud Messaging (GCM) を廃止し](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html)、Firebase Cloud Messaging (FCM) に移行しました。詳細については、[Google から Firebase Cloud Messaging への移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/google-firebase-migration)を参照してください。

<div id="facebook-social-context-field-deprecation">
  ## Facebook Social Context フィールドの非推奨化
</div>

**非推奨化日**: 2019年4月30日

**提供終了日**: 2019年7月30日

2019年4月30日、Facebook は新規アプリケーションでの **Social Context** フィールドの使用を非推奨としました。詳細については、[Facebook Social Context Field Deprecation](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/facebook-social-context-field-deprecation) を参照してください。

<div id="facebook-graph-api-changes">
  ## Facebook Graph API の変更
</div>

**非推奨**: 2018年8月1日

**提供終了**: Graph API v3 は 2019年1月8日にリリース

2018年8月1日以降、Facebook では、リクエスト可能な Facebook Graph API の権限とフィールドが変更されました。Auth0 では、これらの変更を反映して Facebook 接続を更新し、わかりやすくするために接続インターフェイスも変更しました。詳細および重要な日付については、[Facebook Login Changelog: Recent Changes to Facebook Login](https://developers.facebook.com/docs/facebook-login/changelog#2018-07-02) を参照してください。詳しくは、[Facebook Graph API Changes](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/facebook-graph-api-changes) を参照してください。

<div id="lock-v11-and-auth0js-v9">
  ## Lock v11 and Auth0.js v9
</div>

Auth0 では、サービスのセキュリティを継続的に強化しています。その一環として、`/usernamepassword/login` および `/ssodata` のエンドポイントで構成される Legacy Lock API は非推奨となりました。これらのエンドポイントは Lock.js v8、v9、v10 と Auth0.js v6、v7、v8 で使用されており、アプリケーションから直接呼び出すこともできます。

2018年8月6日をもって、Auth0 は Legacy Lock API を恒久的に無効化しました。このサービス終了により、[2018年4月に公表された](https://auth0.com/blog/managing-and-mitigating-security-vulnerabilities-at-auth0/) CSRF 脆弱性は完全に軽減されました。これは、2018年7月16日に最初に案内したソフトリムーバルの猶予期間の終了も意味しており、Legacy Lock API は今後再び有効にできません。

Legacy Lock API への移行がまだ完了していない場合、ユーザーにサービス停止、ログイン失敗、またはその他の悪影響が発生する可能性があります。通常の機能を復旧するには、移行を完了する必要があります。非推奨化に関連するテナントログ内のエラーの発生元を特定するには、非推奨化エラーを確認してください。

<div id="features-affected">
  ### 影響を受ける機能
</div>

現在、Lock v8、v9、v10、または Auth0.js v6、v7、v8 を使用してアプリケーションにログイン機能を実装している場合、この変更の影響を受けます。また、アプリケーションが API 経由で `/usernamepassword/login` または `/ssodata` エンドポイントを直接呼び出している場合も、影響を受けます。

Universal Login を使用しているアプリケーションについては、ログインページ内で使用しているライブラリのバージョンを更新することを推奨します。

ただし、アプリケーションに Lock または Auth0.js を埋め込んで使用している場合や、影響を受ける API エンドポイントを直接呼び出している場合は、更新が必須です。なお、廃止予定のエンドポイントを引き続き使用しているアプリケーションは、サービス終了日以降、正常に動作しなくなります。

ここで明示的に挙げられていないライブラリおよび SDK は、この移行の影響を受けません。

<div id="tenant-log-search-v2-deprecation">
  ## Tenant Log Search v2 の非推奨化
</div>

**非推奨化**: 2019年5月21日

**提供終了**:

* Free: 2019年7月9日
* Essential (旧 Developer) : 2019年8月20日
* Professional (旧 Developer Pro) : 2019年8月20日
* Enterprise: 2019年11月4日

お客様に最も信頼性が高く、スケーラブルなソリューションを提供するため、Auth0 は Tenant Logs Search Engine v2 を非推奨とし、v3 を採用しました。Auth0 では、この変更の影響を受けないお客様については順次移行を進める一方、影響を受ける可能性のあるお客様には、設けられた猶予期間内に v3 へオプトインするよう通知しています。詳細については、[Tenant Log Search v1 から v2 への移行](/docs/ja-jp/troubleshoot/product-lifecycle/past-migrations/migrate-to-tenant-log-search-v3)を参照してください。

<div id="new-ip-addresses-for-allowlisting-in-australia">
  ## オーストラリア向け許可リスト用の新しいIPアドレス
</div>

2017年9月30日より、Auth0はクラウド環境を更新し、オーストラリアからのトラフィックの送信元IPアドレスが新しくなりました。IPアドレスの許可リストを設定している場合は、新しいアドレスをファイアウォールのルールに追加する必要があります。

<div id="features-affected">
  ### 影響を受ける機能
</div>

お使いの環境に接続するカスタムデータベース接続、ルール、またはカスタムメールプロバイダーを使用しており、**かつ** IP アドレス範囲に対してファイアウォール制限を設定している場合は、この変更の影響を受けます。以下の IP アドレスがファイアウォールを通過できるよう、許可されていることを確認してください。

`13.55.232.24, 13.54.254.182, 13.210.52.131, 52.62.91.160, 52.63.36.78, 52.64.84.177, 52.64.111.197, 52.64.120.184, 54.66.205.24, 54.79.46.4, 54.153.131.0`

<div id="new-ip-addresses-for-allowlisting-in-europe">
  ## ヨーロッパ向け許可リスト用の新しい IP アドレス
</div>

2017年9月30日より、Auth0 はクラウド環境を更新し、ヨーロッパからのトラフィックは新しい IP アドレスから送信されるようになりました。IP アドレスの許可リストを設定している場合は、ファイアウォールのルールに新しいアドレスを追加する必要があります。

<div id="features-affected">
  ### 影響を受ける機能
</div>

お使いの環境に接続するカスタムデータベース接続、ルール、またはカスタムメールプロバイダーを使用しており、IPアドレス範囲に対するファイアウォール制限を設定している場合は、この変更の影響を受けます。次の IP アドレスがファイアウォールを通過できるよう、許可されていることを確認してください。

`34.253.4.94, 35.156.51.163, 35.157.221.52, 52.16.193.66, 52.16.224.164, 52.28.45.240, 52.28.56.226, 52.28.184.187, 52.28.212.16, 52.29.176.99, 52.50.106.250, 52.57.230.214, 52.211.56.181, 52.213.216.142, 52.213.38.246, 52.213.74.69`

<div id="cdn-provider-migration-in-the-europe-and-australia-environments">
  ## 欧州およびオーストラリア環境での CDN プロバイダー移行
</div>

2017年7月12日より、Auth0 は Auth0 CDN のスケーラビリティと可用性を向上させました。現在は Amazon CloudFront を使用しています。この変更はすでに米国環境で実施しており、欧州およびオーストラリアでも実施する準備が整いました。

<div id="features-affected">
  ### 影響を受ける機能
</div>

ヨーロッパまたはオーストラリアで、当社のCDNでホストされている Lock を使用している場合、この変更の対象となります。この変更によってアプリケーションに中断や動作の変化が生じることはないため、特に対応は必要ありません。この通知は情報提供のみを目的としたものです。

<div id="password-and-refresh-token-exchange-rules-migration">
  ## パスワード交換およびリフレッシュトークン交換ルールの移行
</div>

2017年5月31日、セキュリティ強化に向けたAuth0の取り組みの一環として、<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> <Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Grant交換 (パスワード交換) およびリフレッシュトークン交換の実行時に、ルールを実行できる機能を追加しました。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この機能を使用しているのは、Authentication API の `/oauth/token` エンドポイントを `grant_type = "password"`、`grant_type = "http://auth0.com/oauth/grant-type/password-realm"`、または `grant_type = "refresh_token"` で呼び出している場合です。

現在これらのフローを使用していて、Dashboard でルールを定義している場合は、影響を受ける可能性があります。スムーズに移行できるよう、お客様のテナントでは、これらの特定のフローに対するルールの実行を無効にしています。今後、これらのルールはすべての新規のお客様、およびまだこれらのフローを使用したことがないお客様に対して実行されます。

`context.protocol` プロパティを確認することで、これらのフローに対する動作を変更するロジックをルールに追加できます。

* `oauth2-password` は、パスワード (および password-realm) フローを示します
* `oauth2-refresh-token` は、Refresh Token フローを示します

必須のオプトイン日より前に、このテナントで新しい動作を有効にしてテストする場合は、[Dashboard](https://manage.auth0.com/#) にログインし、[Tenant Settings > Advanced](https://manage.auth0.com/#/tenant/advanced) で **Run Rules on Password and Refresh Token Exchanges** トグルを有効にしてください。

<div id="account-linking-removal">
  ## アカウントリンクの廃止
</div>

2017年3月1日、Auth0ではセキュリティの強化と標準準拠の向上の一環として、認可コールバック内でのアカウントリンクのサポートを終了しました (つまり、authorize呼び出しの一部としてアクセストークンを受け取ることを廃止しました) 。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この件に関するメール通知を受け取った場合は、この変更の影響を受けています。アカウントのリンクに Management API を使用するようアプリケーションの更新を進める際は、テナントのログで警告を確認することで、引き続き影響を受けているかどうかを確認できます。`authorize` 呼び出しでアクセストークンを送信している場合は、これらのエントリがログに記録されます。

<div id="allowlist-ip-address-ranges">
  ## 許可リストに登録するIPアドレス範囲
</div>

2017年2月20日時点で、Auth0 は米国内の新しいリージョンに拡張され、これらのリージョンから発生するトラフィックには新しいIPアドレスが使用されます。IPアドレスを許可リストに登録している場合は、新しいアドレスをファイアウォールルールに追加する必要があります。

<div id="features-affected">
  ### 影響を受ける機能
</div>

ご利用の環境に接続するカスタムデータベース接続、ルール、またはカスタムメールプロバイダーを使用しており、IP アドレス範囲に対してファイアウォール制限を設定している場合は、この変更の影響を受けます。ファイアウォールのルールに、次の IP アドレスを追加する必要があります。

`138.91.154.99, 54.183.64.135, 54.67.77.38, 54.67.15.170,54.183.204.205, 54.173.21.107, 54.85.173.28, 35.167.74.121, 35.160.3.103,35.166.202.113, 52.14.40.253,52.14.38.78, 52.14.17.114, 52.71.209.77, 34.195.142.251, 52.200.94.42`

<div id="vulnerable-password-flow">
  ## 脆弱なパスワードフロー
</div>

2017年2月1日以前のAuth0のパスワードリセットフローでは、ユーザーはメールアドレスと新しいパスワードを入力できました。これにより、パスワードリセットをリクエストしたことを確認するよう求める確認メールがユーザーに送信されていました。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この問題では、確認リンクがユーザーによって誤ってクリックされると、攻撃者にユーザーのパスワードを変更されるおそれがあります。

Lock バージョン 9 以降では、新しいパスワードリセットフローのみを使用します。Lock 8 以前は、新しいパスワードリセットフローに対応していません。できるだけ早く Lock 9 以降にアップグレードすることを強く推奨します。

<Warning>
  Lock を使用していない場合でも、この脆弱なリセットフローには API 経由で直接アクセスできます。 (詳細については、/dbconnections/change\_password エンドポイント を参照してください。) Auth0 は、現在のフローを使用しているすべてのアプリを直ちに新しいリセットフローへ移行し、この移行を有効にすることを強く推奨しています。
</Warning>

<div id="state-parameter-required-on-redirect-from-rule">
  ## ルールからのリダイレクトでは state パラメーターが必須
</div>

2016年12月6日以降、Auth0 ルールからリダイレクトが行われる場合、Auth0 は HTTP で state パラメーターを生成して送信し、フローが `/continue` エンドポイント に戻る際に、その state パラメーターが有効かどうかを確認します。リダイレクト先のサイトでは、state パラメーターの値を取得し、`/continue` エンドポイント に戻る際にその値をパラメーターとして付与して返す必要があります。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この変更の影響を受けるのは、ルール からリダイレクトしていて、かつ `state` パラメータをまだ保持して `/continue` エンドポイントに返していない場合に限られます。

<div id="delete-all-users-endpoint-change">
  ## すべてのユーザーを削除するエンドポイントの変更
</div>

2016年9月13日以前は、すべてのユーザーを削除するためのエンドポイントは `DELETE /api/v2/users` でした。これは、1人のユーザーを削除するエンドポイントである `DELETE /api/v2/users` と似ています。すべてのユーザーを削除するエンドポイントへの誤送信を防ぐため、URL は `DELETE /api/v2/allusers` に変更されました。これにより、このエンドポイントが意図した場合にのみ呼び出されるようになります。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この変更の影響を受けるのは、現在 `delete all users` エンドポイントを使用している場合のみです。その場合、必要なのは上で説明したとおり URL を変更することだけです。

<div id="email-delivery-template-customization-changes">
  ## メール配信テンプレートのカスタマイズに関する変更
</div>

2016年8月29日以降、Auth0 の組み込みメールプロバイダーは本番環境での利用がサポートされなくなります。Auth0 プロバイダーを使用して送信されるメールは、今後カスタマイズできなくなります。使用できるのは既定のテンプレートのみとなり、送信元アドレスや件名を変更することはできません。

組み込みメールサービスは引き続きテスト目的で使用できますが、アプリを本番環境へ移行する前に、Auth0 がサポートするサードパーティサービス ([Amazon SES](https://aws.amazon.com/ses/)、[Mailchimp](https://mailchimp.com/features/transactional-email/)、[SendGrid](https://sendgrid.com/en-us/pricing)、またはその他の SMTP ベースのプロバイダー) に切り替える必要があります。すでにカスタムメールプロバイダーを使用している場合は、対応は不要です。

<div id="identity-provider-access-tokens-removed-from-user-profile-and-id-token">
  ## ユーザープロファイルおよび ID トークンから削除された ID プロバイダーのアクセストークン
</div>

2016 年 8 月 8 日以降、Auth0 Authentication API から返されるユーザープロファイル JSON オブジェクト (ID トークン) の形式が変更され、ユーザープロファイルの `identities` 配列に含まれていた ID プロバイダーのアクセストークンは削除されました。

ユーザーの ID プロバイダーのアクセストークンを取得するには、`read:user_idp_tokens` スコープで生成された API トークンを指定して、`/api/v2/users/{user-id}` エンドポイントに HTTP GET リクエストを送信する必要があります。Auth0 ルールの `user` 引数では、引き続き ID プロバイダーのアクセストークンにアクセスできます。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この変更の影響を受けるのは、ルール外で Identity Provider のアクセストークン (ユーザープロファイル内の `identities[0].access_token`) を使用し、Identity Provider 経由で他のサービス (Facebook Graph API、Google APIs など) を呼び出している場合のみです。変更後に作成されたテナントには、この更新が自動的に適用されます。

<div id="tokeninfo-endpoint-validation">
  ## Tokeninfo エンドポイントの検証
</div>

2016年6月1日以降、Tokeninfo エンドポイントを呼び出す際は、API 呼び出しの URL (たとえば `https://{yourDomain}/`) が、検証する ID トークンの `iss` 属性の値と一致している必要があります。これらの値が一致しない場合、レスポンスは `HTTP 400 - Bad Request` となります。

<div id="features-affected">
  ### 影響を受ける機能
</div>

Tokeninfo エンドポイントを直接呼び出している場合は、検証する ID Token の `iss` 属性の値が Auth0 テナントの名前空間 `https://{yourDomain}/` と一致していることを確認してください。`iss` 属性の値を確認するには、[jwt.io](https://www.jwt.io/) を使ってトークンをデコードできます。

<div id="email-delivery-from-address-changes">
  ## メール送信元アドレスの変更
</div>

2016 年 4 月 27 日より、Auth0 の組み込みメールプロバイダーでは、すべてのメールがあらかじめ定義された送信元アドレス (`no-reply@auth0user.net`) から送信されるようになりました。カスタムメールプロバイダーは現在無料で利用できます。"from" アドレスをカスタマイズするには、Auth0 がサポートするサードパーティサービス ([Amazon SES](https://aws.amazon.com/ses/)、[Mailchimp](https://mailchimp.com/features/transactional-email/)、[SendGrid](https://sendgrid.com/en-us/pricing)) またはその他の SMTP ベースのプロバイダーに切り替えることができます。すでにカスタムメールプロバイダーを使用している場合は、変更はありません。

<div id="patch-and-post-endpoints-no-longer-accept-secret_encoded-flag">
  ## PATCH および POST エンドポイントでは secret\_encoded フラグが受け付けられなくなりました
</div>

`jwt_configuration.secret_encoded` 設定は、PATCH および POST の applications エンドポイントでは受け付けられなくなりました。

OIDC 仕様への準拠をさらに強化するため、Auth0 は新しいアプリケーションに対して base64 エンコードされたアプリケーションシークレットを生成または受け付けなくなります。

エンコードされたシークレットが保存されている既存のアプリケーションはそのまま維持され、変更もありませんが、新しいアプリケーションでは base64 エンコーディングは使用されなくなります。その結果、`secret_encoded` フラグは不要となり、受け付けられなくなりました。

<div id="features-affected">
  ### 影響を受ける機能
</div>

この変更の影響を受けるのは、これらのエンドポイントを直接利用している場合のみです。