過去の移行

これらの移行は、すべてのお客様に対してすでに有効です。ご不明な点がありましたら、サポートセンターでチケットを作成してください。

廃止：2024年6月5日

サポート終了（EOL）：2024年8月5日

Auth0サポートセンター内にあるサブスクリプションチケットの閲覧アクセスは、2024年8月5日に変更されました。テナント内の全ユーザーによって作成された全サポートチケットを閲覧および管理するアクセスを維持するには、新しい「昇格されたサポートアクセス」ロールが必要です。

廃止：2023年12月7日

サポート終了（EOL）：2024年2月5日

パスワードリセットリンクとメール検証リンクは、テナントログに記録されなくなりました。これらのリンクは、パスワードリセットまたはメール検証のManagement API要求応答から取得できます。

廃止：2023年9月5日（パブリッククラウド）、2023年11月21日（プライベートクラウド）

サポート終了（EOL）：2024年2月21日

本変更により、リダイレクションベースのログインフローの最長有効期間が1時間になりました。完了までに1時間を超えるログインフローは、ユニバーサルログインとクラシックログインの両方で、期限切れになります。期限切れになると、その後のエンドユーザーのブラウザーからのアクション（メールアドレス/パスワードの入力、アクション/ルールへのリダイレクトなど）は、次のいずれかの結果になります。

• 紐づけられたアプリケーションのデフォルトのログインルートにリダイレクトされ、新しいログイントランザクションとしてフローが再開される

• デフォルトのログインルートが構成されていない場合は、エラーページが表示される

廃止：2023年7月12日

サポート終了（EOL）：2024年1月17日

当社では、未登録スコープを要求できないようにするため、リフレッシュトークン交換時のスコープ評価の改善に努めています。（テナントに登録されているAPIの）audまたはaudience値に対して登録されていないカスタムスコープ値は、未登録スコープとみなされます。

この変更により、APIスコープ評価には、ユーザー認証時に要求された、または拡張性（ルールなど）を介してインジェクトされたカスタムスコープがすべて含まれるようになります。この評価では、すべてのスコープが登録済みであることを確認し、未登録のスコープがあればエラーを返します。

廃止：2023年4月27日

サポート終了（EOL）：2023年6月30日（express-oauth2-bearer）、2023年10月27日（angular-auth0およびauth0-cordova）

以下のリポジトリを廃止しました。

• express-oauth2-bearer | 移行ガイド

• angular-auth0 | 移行ガイド

• auth0-cordova | 移行ガイド

これらのライブラリーは今後サポートされません。これらの日付までに、進行中のプロジェクトからこれらのライブラリーを削除してください。

ご不明な点や懸念がありましたら、GitHubでお問い合わせください。

移行日：2023年9年11日

Actionsを通じて長期サポート（LTS）Node.jsの今後すべてのバージョンをサポートし、Node JS開発者コミュニティと連携するという当社ミッションの一環として、Node 16の長期サポートが有効な間にNode 18をリリースしました。利用しているすべてのお客様は、早急にNode 18に移行し、長期サポートを最大限活用することを推奨します。Node 16長期サポートは9月まで利用可能ではありますが、長期サポート終了後の使用には一定のリスクを伴うため、Node 18にアップデートすることを推奨いたします。

Node.js 18は、弊社の一連の拡張オファリングにおいて、一般利用可能（GA）になりました。これは、Actions、Rules、Hooks、データベーススクリプト、カスタムソーシャル接続を含みます。コードセキュリティのベストプラクティスに従うため、2023年9月11日までにNode 18にアップデートすることを強くお勧めします。

廃止：2022年12月21日

サポート終了（EOL）：2023年6月21日

2023年6月21日以降、Auth0は拡張機能においてNode.jsから.NETおよびC#の実行をサポートしなくなりました。Auth0は以前、edge.jsと呼ばれるNode.jsモジュールを介してルール、フック、およびカスタムデータベーススクリプトの拡張コードを記述するためにC#言語のサブセットをサポートしていました。

拡張機能におけるNode.jsからの.NETおよびC#の実行のサポートを廃止することは、信頼されていないコードを実行するためのパフォーマンスの高い安全なプラットフォームを維持するために重要です。この変更によって、次世代の拡張機能の改善を進めることが可能になりました。詳しくは、「edge.js拡張機能から移行する」をお読みください。

廃止：2022年12月21日

サポート終了（EOL）：2023年6月21日

Auth0は2023年7月31日以降、Sharepoint 2010/2013のauth0-claims-providerアドオンをサポートしなくなりました。

2023年6月21日以降、Auth0は拡張機能においてNode.jsからOracleデータベースへの接続をサポートしなくなりました。Auth0は以前、oracledbと呼ばれるNode.jsモジュールを介してRules、Hooks、カスタムデータベーススクリプトの拡張コードからOracleデータベースへの接続をサポートしていました。

機能拡張におけるNode.jsからOracleデータベースへの接続のサポートを廃止することは、信頼されていないコードを実行するためのパフォーマンスの高い安全なプラットフォームを維持するために重要です。この変更によって、次世代の拡張機能の改善を進めることが可能になりました。

詳しくは、「oracledb拡張機能から移行する」をお読みください。

廃止：2023年01月31日

サポート終了（EOL）：2023年7月31日

Auth0は2023年7月31日以降、Sharepoint 2010/2013のauth0-claims-providerアドオンをサポートしなくなりました。このアドオンがないと、Auth0接続で「Sharepointユーザー選択機能」を使用してSharepoint 2010/2013ユーザーに権限を割り当てることができなくなります。

2023年7月31日までに、auth0-claims-providerとのすべての統合を削除する必要があります。これ以降、残っているauth0-claims-providerとの統合はすべて正常に機能しなくなり、アプリケーションのユーザーに影響を与える可能性があります。

廃止：2022年11月09日

サポート終了（EOL）：2023年5月9日

パフォーマンス向上のため、チェックポイントページネーション方法が使用されている場合、ロールユーザー取得のManagement APIエンドポイントは合計1,000件を超える結果のみを返していました。このページネーション方法は、大量の結果をサポートするように最適化されています。オフセットのページネーション方法では、1,000件の結果が上限になります。

この2つのページネーション方法の実装に関する詳細は、「ロールユーザー取得エンドポイントのManagement APIドキュメント」をお読みください。

廃止：2022年7月28日（パブリッククラウド）、2022年8月31日（プライベートクラウド）

サポート終了（EOL）：2023年1月30日（パブリッククラウド）、2023年4月18日（プライベートクラウド）

パブリッククラウドでは2023年1月30日、プライベートクラウドでは2023年4月18日より、Authentication APIの/userinfoエンドポイントからの応答で、Auth0 Actionsを使用して、名前空間のないカスタムクレームをJWTトークンに追加することが許可されるようになりました。以前は、拡張コード（Rules/Hooks/Actions）経由のアクセストークンおよびIDトークンで名前空間のあるクレームが許可されていました。カスタムクレームへの移行により、プライベートの名前空間のあるカスタムクレームと、OIDCユーザープロファイルクレームが、アクセストークンに追加できるようになります。IDトークンは現在、ユーザープロファイルクレームをサポートしており、追加でプライベートの名前空間のないカスタムクレームがサポートされます。これらのクレームは、Auth0の/userinfoの応答にも追加されます。移行を開始するには、「カスタムクレームの移行ガイド」をお読みください。

テナントで拡張コード（Rules / Hooks / Actions）を実行して、サポート終了が来るまでは無視される名前空間のないカスタムクレームを設定しようとしている場合、これらのクレームがトークンと/userinfoの応答に表示されてしまいます。構成とAuth0のログを確認することをお勧めします。

名前空間のないプライベートクレームの追加に伴い、Auth0ではテナントに影響を及ぼす可能性のある以下の制限を適用しました。

• カスタムクレームのペイロードを最大100KBに制限します。

• OpenIDの標準クレームまたはAuth0が内部で使用するクレームのカスタマイズおよび変更を制限します。

• 将来的に、Auth0は上記のリストに含まれていないその他のクレームの使用についても制限する可能性があります。その場合は、移行に必要な時間を確保してお客様に通知します。

• /userinfoエンドポイントを除き、Auth0オーディエンスを伴うアクセストークンでのプライベートかつ名前空間のないカスタムクレームの作成を制限します。

• 指定されたOIDCユーザープロファイルクレームしかアクセストークンには追加できません。

• 「$」の文字で始まるカスタムクレームの作成を制限します。

カスタムクレームの詳細については、「カスタムクレームを作成する」をご確認ください。

廃止：2022年06月13日

サポート終了（EOL）：2023年1月31日

当社では、最新のKubernetesベースのテクノロジースタックを導入し、併せてデータベースをアップグレードすることで、Auth0プライベートクラウドを支える基盤となるインフラストラクチャの改善に努めています。Auth0プライベートクラウドのすべてのご利用者の協力を得て、今年中にプライベートクラウドの導入を新しいインフラストラクチャスタックにアップグレードしており、2023年1月31日までに古いスタックを廃止しました。

また、2205（2022年5月リリース）は、従来のプライベートクラウドプラットフォームの最後の公式リリースです。バグやセキュリティの脆弱性があれば評価し、必要に応じてパッチのリリースによって対処します。  新たなインフラストラクチャスタックにアップグレードする前に、アップグレード作業を効率化するため、環境を互換性のある最小バージョンに更新する必要があります。

ご不明な点がありましたら、担当のテクニカルアカウントマネージャーまでお問い合わせください。

廃止：2022年5月4日（パブリッククラウド）、2022年6月9日（プライベートクラウドリリース2205）

サポート終了（EOL）：2023年5月02日（パブリッククラウド）、2023年1月06日（プライベートクラウド）

パブリッククラウドでは2022年5月4日、プライベートクラウドでは2022年6月9日をもって、以下のAuth0ログ拡張機能が廃止されました。

• Auth0 Authentication API Webhooks

• Auth0 Management API Webhooks

• Logs to Cloudwatch

• Logs to Logentries

• Logs to Loggly

• Logs to Logstash

• Logs to Papertrail

• Logs to Splunk

• Logs to Sumo Logic

廃止：2022年11月02日（パブリッククラウド）、2022年12月21日（プライベートクラウド）

サポート終了（EOL）：2023年5月02日（パブリッククラウド）、2023年5月31日（プライベートクラウド）

パブリッククラウドでは2022年11月2日、プライベートクラウドでは2022年12月21日をもって、以下のAuth0ログ拡張機能が廃止されました。

• Logs to Segment

• Logs to Mixpanel

• Logs to AppInsights

• Logs to Azure Blob Storage

上記のログ拡張機能はすべて廃止されました。同等の機能をセットアップするのに使用できるのは、ログイベントストリームまたはAuth0 Marketplace統合です。パブリッククラウドでは2022年11月2日、プライベートクラウドでは2022年12月21日をもって、上記のインストール済みログ拡張機能のサポートは行われなくなりました。詳しくは、「ログ拡張機能から移行する」をお読みください。

廃止：2021年12月9日および2021年12月（プライベートクラウドリリース2112.2）

サポート終了（EOL）：2022年6月9日および2022年9月9日（プライベートクラウド）

パブリッククラウドでは2022年6月9日、プライベートクラウドでは2022年9月9日以降、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> （エンタープライズ接続プロビジョニングエンドポイント）

詳しくは、「テナントホスト名検証の移行」をお読みください。

サポート終了（EOL）：2022年4月30日

2022年4月30日に、Node.js v12の長期サポート（LTS）が終了しました。このため、Node.js開発チームは重要なセキュリティ修正をこのバージョンに移植できません。これにより、拡張コードが潜在的にセキュリティの脆弱性にさらされる可能性があります。そのため、Auth0はNode 12からNode 16に移行しています。

Node 16のアップデートでは、Node.jsの標準ライブラリーに破壊的変更はありません（ルールとカスタムデータベースのアクションスクリプトは影響を受けます。詳細は「破壊的変更 - ルールとカスタムデータベースのアクションスクリプトのみ」セクションを参照）が、Node v12を利用しているお客様は、セキュリティとコンプライアンスのために、長期サポート（LTS）が有効なNodeバージョンを最新の状態に維持してください。Node 8を利用しているお客様は、セキュリティコンプライアンスに違反しているため、Node 16に移行して、セキュリティリスクを排除する必要があります。Auth0は2022年2月22日にNode 8のランタイムをパブリッククラウドのテナントで削除し、2022年4月にはプライベートクラウドのリリースで削除しました。これらの日付以降にNode 8が設定されたままのテナントでは、サービス中断の可能性があります。

廃止：2021年10月7日（パブリッククラウド）、2021年12月（プライベートクラウド）

サポート終了（EOL）：2022年4月12日（パブリッククラウド）、2022年06月30日（プライベートクラウド）

パブリッククラウドでは2022年4月12日、プライベートクラウドでは2021年12月以降、アクセストークンと認可コードは、OAuth仕様のRFC6749をサポートし、クライアントが認可コードとアクセストークンの値について推測することを防ぐため、可変長で発行されるようになりました。現在、アクセストークンと認可コードのサイズは固定です。認可コードの現在のサイズは、一部のセキュリティの専門家が推奨するサイズよりも短いものです。この変更により、コードとトークンが強化されると共に、Auth0システムのパフォーマンスが改善されます。

特定の長さのアクセストークンと認可コードに依拠したシステム構成をご利用のお客様は、パブリッククラウドでは2022年4月12日、プライベートクラウドでは2022年6月30日のリリースまでに、固定サイズから可変サイズの構成に変更する必要がありました。

廃止：2020年4月15日

サポート終了（EOL）：2022年2月25日（パブリッククラウド）、2022年4月（プライベートクラウドリリース）

2019年12月13日より、Node.js v8は長期サポート（LTS）の対象外となりました。これにより、今後は重要なセキュリティ修正がこのバージョンには移植されません。Node 8を利用しているお客様は、セキュリティコンプライアンスに違反しているため、Node 12に移行して、セキュリティリスクを排除する必要があります。テナントレベルのNodeのバージョンを8から12に移行する詳しい方法については、「Node.js 8からNode.js 12に移行する」をお読みください。

Node.js v12についても2022年に長期サポート（LTS）が終了したため、RulesとHooksをご利用のお客様はすべて早急に、遅くともNode.jsコミュニティによるNode 12のサポートが正式に終了する2022年4月30日までに、Node 16を使用するActionsに移行することを強くお勧めします。移行の手順の詳細については、「RulesとHooksをActionsに移行する」をお読みください。

廃止：2021年5月5日（パブリッククラウド）

サポート終了（EOL）：2021年11月3日（パブリッククラウド）

Auth0の旧ネットワークエッジはパブリッククラウド上で機能しなくなりました。2021年11月3日以降、新しいAuth0ネットワークエッジへの移行を完了していないパブリッククラウドテナントは、トラフィックを受信しなくなりました。カスタムドメインの新規作成はすべて、自動的に新たなネットワークエッジで行われます。

廃止：2020年7月21日（パブリッククラウド）

サポート終了（EOL）：2021年1月26日（パブリッククラウド）、2022年2月（プライベートクラウドリリース）

2021年1月26日以降、以下のManagement API v2エンドポイントへの要求は、パブリッククラウドテナントのアイテムを最大50返すようになりました。より多くのアイテムを取得するには、pageおよびper_pageパラメーターを含める必要があります。2020年7月21日から、Auth0はこの変更に備えて、テナントログおよび移行トグルを表示するようになりました。

• GET /api/v2/clients

• GET /api/v2/client-grants

• GET /api/v2/grants

• GET /api/v2/connections

• GET /api/v2/device-crecentials （typeクエリパラメーターが使用される場合）

• GET /api/v2/resource-servers

• GET /api/v2/rules

2020年7月21日より前に作成されたパブリッククラウドテナント、およびper_pageパラメーターを渡さずに、複数の結果を返す可能性があるクエリを作成し、影響を受けるエンドポイントをアクティブに呼び出しているパブリッククラウドテナントは、すべてこの影響を受けるようになりました。2020年7月21日以降に作成されたテナント、影響を受けるエンドポイントを使用しないテナント、影響を受けるエンドポイントを使用するがper_pageパラメーターを渡すテナント、または結果を常に1つだけ返すクエリを作成するテナントについては、影響を受けません。詳細については、「Management API v2エンドポイントの移行：クエリのページネーション」をお読みください。

廃止：2021年6月17日

サポート終了（EOL）：2021年12月20日

すべてのAuth0の導入で一貫性を確保し、Auth0のカスタムドメイン機能の強化に焦点をあてるため、プライベートクラウドのカスタムドメイン機能を2021年12月20日をもって終了しました。一貫性を保つことで、この機能を強化し、信頼性の問題をより迅速に修正して、運用効率を向上させることができ、利用者はカスタムドメインをよりスピーディーに活用できるようになりました。Auth0カスタムドメインへの移行に関する詳細は、「プライベートクラウドのカスタムドメインを移行する」でお読みください。

廃止：2021年5月25日

サポート終了（EOL）：2021年12月1日

2021年12月1日にログアウトの動作が変更され、ログアウトの実行中にIDプロバイダーから/login/callbackに渡されるreturnToクエリパラメーターを使用する代わりに、Auth0ログアウトAPIに渡されるURIにユーザーを常にリダイレクトするようになりました。これらいずれかのAPIへの以前の呼び出し記録がAuth0にない場合、ログアウトは完了しますが、リダイレクトは起こらず、エンドユーザーにはエラーページが表示されます。詳しくは、「ログアウトリダイレクトの移行ガイド」をお読みください。

廃止：2021年2月1日

サポート終了（EOL）：2021年9月30日（パブリッククラウド）、2021年9月（プライベートクラウド月次リリース）

DashboardへのRole-based Access Controlが変更されました。定められていたアプリケーション管理者ロールは廃止されました。2021年2月1日以降、管理者は、廃止されたアプリケーション管理者ロールを使用してメンバーを招待することができなくなりました。既存のアプリケーション固有の管理者は、サポート終了日まで、引き続き既存の権限セットを使用してDashboardを使用することが可能でした。

新しいDashboardロールセットは、アクセスが制限された閲覧者と編集者ロールを含み、チームメンバー間の改善された、安全な共同作業を可能にします。新しい編集者 - 特定のアプリロールは、編集者ロールがサポートされているサブスクリプションプランで、以前のアプリケーション管理者ロールに代わるものです。

以下の条件に該当するテナントはこの廃止の影響を受けます。

• 2021年2月1日より前に作成された

• アプリケーション管理者ロールのテナントメンバーが1人以上いる

• Dashboardロール機能のプレビューにオプトインしていない

2021年2月1日から、この変更に備えて、移行トグルが表示されました。詳しくは、「Dashboard管理の新しいロールに移行する」をお読みください。

廃止：2021年1月19日

サポート終了（EOL）：2021年5月10日（パブリッククラウド）、プライベートクラウド6月リリース（v2106）

パブリッククラウドでは2021年5月10日、プライベートクラウドでは6月リリース（v2106）をもって、Auth0ネットワークエッジはTLS 1.0またはTLS 1.1のトラフィックを受け入れなくなりました。これらの旧プロトコルは安全性が低く、業界でよく知られている弱点や脆弱性がありました。セキュリティを強化するため、すべてのAuth0クライアントはTLS 1.2以降にアップグレードする必要があります。詳細と手順はアプリケーションによって異なります。詳しくは、Auth0コミュニティに投稿されている「TLS 1.2へのアップグレード：必要な手順」をお読みください。

廃止：2018年1月

サポート終了（EOL）：2021年1月

Auth0は、ロックを使用してFacebookとGoogleアナリティクスを追加するauth0-analytics.js libraryの使用を廃止しました。これはロックのイベントを待ち受け、それをAuth0-tag-manager.jsライブラリーに渡します。一部のレガシーのケースではまだ機能する場合があります。このライブラリーは今後はメンテナンスされません。auth0-tag-manage.jsを使用してFacebookやX、Googleなどのサードパーティ分析ライブラリーへのプロキシ要求を管理するには、カスタムコードを記述する必要があります。

廃止：2020年8月31日

サポート終了（EOL）：2020年12月17日

Auth0では、GET /api/v2/device-credentialsエンドポイントを使用する際にuser_idの提供が必須になりました。要求にuser_idが含まれていない場合、400ステータスコードが返されます。テナントログでdepnoteをチェックして、この廃止の影響を受けるかどうかを確認してください。詳しくは、「廃止エラーを確認する」をお読みください。

Auth0ではこの廃止の影響を受けるテナントを特定し、各管理者にお知らせしています。ご利用のテナントがuser_idを使用せずに要求を行っている場合は、早急に変更してください。

廃止：

• パブリッククラウド：2020年11月18日

• プライベートクラウド：2020年12月1日

サポート終了（EOL）：

• パブリッククラウド：2021年5月18日

• プライベートクラウド：プライベートクラウド6月リリース（v2106）

Auth0では以前、Microsoft Entra IDおよびADFS接続のemail_verifiedフィールドをtrueに設定していました。この廃止日より前にEntra ID/ADFS接続を利用していた場合は、メール検証の接続設定をオーバーライドして以前の動作を維持するテナント設定があります。

パブリッククラウドでは2021年5月18日に、プライベートクラウドでは6月リリース（v2106）で、すべてのEntra ID/ADFS接続で接続レベルのプロパティの使用が開始されました。この日付の前に、すべての接続が正しく構成されていることをご確認ください。詳細は、「Entra IDとADFSのメール検証」をお読みください。

発効：2020年2月

Google Chrome v80でクッキーの処理方法が変更されました。Auth0はこれを受けて、クッキーの処理方法を以下のように変更しました。

• samesite属性が設定されていないクッキーは、laxに設定されます

• sameSite=noneのクッキーは、セキュリティ保護が必要です。保護されていない場合、ブラウザーに保存できません

これらの変更は、セキュリティの強化とCSRF攻撃からの防御を目的としています。詳しくは、「SameSiteクッキー属性の変更」をご覧ください。

廃止：2018年11月10日

サポート終了（EOL）：2019年6月30日（パブリッククラウド）、2021年5月（プライベートクラウド月次リリース）

パブリッククラウドでは、ユーザー検索v2が廃止されており、2019年6月30日より前にすでに対処されているはずです。移行を完了させる必要があるお客様には、通知が送信されました。

プライベートクラウドでは、5月のプライベートクラウド月次リリース後にユーザー検索v1およびv2エンドポイントが利用できなくなり、新しいユーザー検索ｖ3エンドポイントに置き換わりました。

呼び出しがアプリケーションに代わって行われたことをAuth0が認証できない場合の、機密アプリケーションからの/passwordless/startエンドポイントの使用が廃止されました。詳しくは、「機密アプリケーションからのパスワードレスエンドポイントに移行する」をお読みください。ユニバーサルログインのクリックジャッキング対策の変更

クリックジャッキングを防止するため、ログインページをiframeでレンダリングする場合にヘッダーを追加するオプトインが追加されました。この機能を有効にすることを強くお勧めします。詳しくは、「ユニバーサルログインのクリックジャッキング防止の変更」をご覧ください。

廃止：2018年3月31日

サポート終了（EOL）：未定

Auth0では、一部のユーザーとデバイスのエンドポイントを呼び出すための資格情報としてのIDトークンの使用を廃止し、代わりにアクセストークンを使用するように変更しました。詳しくは、「アクセストークンを使用したManagement APIエンドポイントに移行する」と「アクセストークンを使用したユーザーアカウントのリンクに移行する」をご覧ください。

廃止：2017年7月8日

サポート終了（EOL）：未定

2017年7月8日をもって、パスワード接続とパスワードレス接続の両方の/oauth/roエンドポイントが廃止されました。同じ機能性を/oauth/tokenエンドポイントを使用して実装できます。詳しくは、「リソース所有者のパスワードフローの移行」をお読みください。

廃止：2016年10月

サポート終了（EOL）：

• パブリッククラウド：2020年7月13日

• プライベートクラウド：2020年11月月次リリース

Management API v1は、パブリッククラウドで2020年7月13日にサポート終了となりました。Management API v1は2020年11月の月次リリースまでプライベートクラウドに含まれ、これがManagement API v1を含まない最初のリリースとなりました。サービスの中断を防ぐため、この日付までに措置を講じる必要がある可能性があります。この移行を完了する必要があるお客様へは、すでに通知が送信されており、今後も引き続きお知らせが送信されます。

廃止：2020年3月5日

サポート終了（EOL）：2020年3月31日

Facebookは、Instagramの旧APIを2020年3月31日に停止することを発表しました。Instagramを使用したログインを実装する代替ツールは提供されません。詳しくは、「Instagram接続の廃止」をご覧ください。

廃止：2020年3月1日

サポート終了（EOL）：2020年3月1日

Yahooは、ユーザープロファイルとそれに含まれる情報を取得する方法を変更しました。詳しくは、「Yahoo APIの変更」をご覧ください。

廃止：2019年4月11日

サポート終了（EOL）：2019年4月11日

2019年4月11日をもって、Googleクラウドメッセージング（GCM）をGoogleが廃止し、Firebaseクラウドメッセージング（FCM）に置き換えました。詳しくは、「GoogleクラウドメッセージングからFirebaseクラウドメッセージングへの移行」をご覧ください。

廃止：2019年4月30日

サポート終了（EOL）：2019年7月30日

Facebookは、2019年4月30日に、新規アプリケーションのソーシャルコンテキストフィールドの使用を廃止しました。詳しくは、「Facebookソーシャルコンテキストフィールドの廃止」をご覧ください。

廃止：2018年8月1日

サポート終了（EOL）：2019年1月8日リリースのGraph API v3

Facebookは、2018年8月1日に、要求できるFacebook Graph APIのアクセス許可とフィールドを変更しました。Auth0は、これらの変更を反映するためにFacebook接続を更新し、明確にするために接続インターフェイスを変更しました。完全な詳細と主な日付については、「Facebookログインの更新履歴：Facebookログインに対する最新の変更」を参照してください。詳しくは、「Facebook Graph APIの変更」をご覧ください。

当社ではサービスのセキュリティを継続的に改善しています。この一環として、/usernamepassword/loginおよび/ssodataエンドポイントで構成される旧Lock APIを廃止しました。これらのエンドポイントは、Lock.jsのv8、v9、v10、およびAuth0.jsのv6、v7、v8で使用され、アプリケーションからも直接呼び出せます。

2018年8月6日時点で、Auth0は旧Lock APIを完全に廃止しました。このサービスの削除により、2018年4月に公開されたCSRFの脆弱性が完全に軽減されます。これに伴い、2018年7月16日に最初に発表された削除の猶予期間も終了し、今後は旧Lock APIを再有効化することはできません。

旧Lock APIの移行がまだ完了していない場合、ユーザーがサービスの停止、ログインの失敗、その他の不都合な影響を受ける可能性があります。通常の機能を回復するには、移行を完了する必要があります。エラーの原因を特定するには、廃止に関連するテナントログで廃止エラーを確認してください。

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

ユニバーサルログインを使用するアプリケーションでは、ログインページ内で使用するライブラリーのバージョンを更新することをお勧めします。

ただし、アプリケーションに組み込みのLockまたはAuth0.jsを使用している場合、または影響を受けるAPIエンドポイントを直接呼び出している場合は、更新が必須となり、廃止されたエンドポイントをまだ使用しているアプリケーションは、サービス削除日以降、正常に機能しなくなります。

ここに明記されていないライブラリーおよびSDKは、この移行による影響を受けません。

廃止：2019年5月21日

サポート終了（EOL）：

• 無料：2019年7月9日

• エッセンシャル（旧デベロッパー）2019年8月20日

• プロフェッショナル（旧デベロッパープロ）：2019年8月20日

• エンタープライズ：2019年11月4日

最も信頼できるスケーラブルなソリューションをお客様に提供するために、Auth0は、v3を支持して、テナントログ検索エンジンv2を廃止しました。Auth0は、この変更の影響を受けないお客様を積極的に移行しながら、影響を受ける可能性があるお客様に対しては、猶予期間中にv3のオプトインを行うよう通知しました。詳しくは、「テナントログ検索v1からV2に移行する」をご覧ください。

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

環境に接続するカスタムデータベース接続、ルール、またはカスタムメールプロバイダーをご利用で、かつ、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

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

環境に接続するカスタムデータベース接続、ルール、またはカスタムメールプロバイダーをご利用で、かつ、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

2017年7月12日時点で、Auth0 CDNのスケーリングと可用性が改善されました。以降はAmazon CloudFrontが使用されます。この変更は米国環境ですでに適用されており、新たにヨーロッパとオーストラリアで準備が整っています。

ヨーロッパまたはオーストラリアで（CDNがホストする）Lockをご利用の場合、この影響を受けます。この変更によってアプリケーションの動作に中断や変更は生じないため、対応は必要ありません。この通知はお知らせのみを目的としています。

2017年5月31日に、セキュリティ強化の一環として、OAuth 2.0リソース所有者のパスワード付与交換（パスワード交換）およびリフレッシュトークン交換時に、ルールを実行する機能が追加されました。

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

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

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

• oauth2-passwordはパスワード（およびpassword-realm）の交換を示します

• oauth2-refresh-tokenはリフレッシュトークンの交換を示します

オプトインが義務化される日より前に、このテナントで新しい動作をテスト用に有効にしたい場合は、［Dashboard］にログインして、［テナント設定］>［詳細設定］で［パスワードとリフレッシュトークンの交換ルールを実行する］を有効にします。

2017年3月1日に、セキュリティ向上および規格準拠の一環として、認可コールバックの一部としてのアカウントリンキング（すなわち、認可呼び出しの一部としてのアクセストークンの受け入れ）のサポートを停止しました。

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

2017年2月20日時点で、Auth0は新たな米国地域に拡大しており、これらの地域からのトラフィックには新しいIPアドレスが割り当てられます。IPアドレスを許可リストに登録する場合は、新しいアドレスをファイアウォールルールに追加する必要があります。

環境に接続するカスタムデータベース接続、ルール、またはカスタムメールプロバイダーをご利用で、かつ、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

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

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

Lockのバージョン9以降では、新しいパスワードリセットフローのみが使用されています。Lock 8以前は、新しいパスワードリセットフローを処理しません。できる限り早急にLock 9以降にアップグレードすることを強くお勧めします。

2016年12月6日時点で、リダイレクトがAuth0ルールから行われると、Auth0はHTTPで状態パラメーターを生成して送信し、フローが/continueエンドポイントに戻った際に有効な状態パラメーターを確認します。リダイレクト先のサイトは状態パラメーターの値を取得し、/continueエンドポイントに戻る際にパラメーターとしてそれを追加することで戻す必要があります。

影響を受けるのは、ルールからリダイレクトし、状態パラメーターを取得も（/continueエンドポイントに）返しもしていない場合のみです。

2016年9月13日より前には、すべてのユーザーを削除するエンドポイントはDELETE /api/v2/usersでした。これは、1人のユーザーを削除するエンドポイント、DELETE /api/v2/usersに非常に似ています。そこで、誤って全ユーザー削除エンドポイントを要求してしまうことを防ぐため、URLがDELETE /api/v2/allusersに変更されました。これにより、このエンドポイントへの呼び出しが意図的にのみ行われることを想定しています。

現在、全ユーザー削除エンドポイントを使用している場合のみ、この変更の影響を受けます。使用している場合は、上記で説明しているURLに変更してください。

2016年8月29日をもって、Auth0の組み込みのメールプロバイダーは、運用環境での使用がサポートされなくなりました。Auth0プロバイダーを使用して送信されたメールは、カスタマイズできなくなりました。今後はテンプレートに制限され、差出人アドレスや件名を変更できません。

組み込みのメールサービスはテスト目的でまだ使用できる場合がありますが、アプリを運用環境に移行する前に、Auth0がサポートするサードパーティサービス（Amazon SES、Mandrill、SendGrid）またはその他のSMTPベースのプロバイダーに切り替える必要があります。すでにカスタムメールプロバイダーをご利用の場合は、対応は必要ありません。

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

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

ルール外でIDプロバイダーアクセストークン（ユーザープロファイルのidentities[0].access_token）を使用し、IDプロバイダー（Facebook Graph API、Google APIなど）から他のサービスを呼び出している場合のみ、この変更の影響を受けます。テナントが変更後に作成された場合、この更新は自動的に行われます。

2016年6月1日時点で、Tokeninfoエンドポイントの呼び出しの際に、API呼び出しのURL（https://{yourDomain}/など）は、検証されるIDトークンのiss属性の値と一致しなければなりませんでした。これらの値が一致しない場合、応答がHTTP 400 - Bad Requestになります。

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

2016年4月27日より、Auth0の組み込みのメールプロバイダーがすべてのメールを事前設定された差出人アドレス（no-reply@auth0user.net）から送信するようになりました。カスタムメールプロバイダーは無料になりました。「差出人」アドレスをカスタマイズするには、Auth0がサポートするサードパーティサービス（Amazon SES、Mandrill、SendGrid）または他のSMTPベースのプロバイダーに切り替えることができます。すでにカスタムメールプロバイダーをご利用の場合は、変更はありません。

jwt_configuration.secret_encoded構成は、アプリケーションのPATCHおよびPOSTエンドポイントによって受け入れられなくなりました。

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

エンコードされたシークレットが保存されている既存のアプリケーションが変更されることはありませんが、新しいアプリケーションではbase64のエンコードは使用されません。結果として、secret_encodedフラグは今後受け入れられることはなく、必要ありません。

これらのエンドポイントと直接やり取りする場合のみ、この変更の影響を受けます。