メインコンテンツへスキップ
以下は、すべてのお客様ですでに有効になっている移行です。ご不明な点がある場合は、Support Center でチケットを作成してください。

​
非カスタムのソーシャル接続における保護対象プロパティ

非推奨: 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 統合として提供される接続は含まれません。

​
Management API によるユーザー更新後の不要なセッション削除

非推奨: 2025年2月11日 サポート終了: 2025年8月19日 の ユーザーを更新 エンドポイント (PATCH /api/v2/users/{id}) では、次の場合、データベース接続ユーザーのセッションは無効化されなくなります。
  • email または email_verified 属性が、変更されていない値に設定されている場合。
  • email_verified 属性が true に設定されている場合。

​
HTTPS リクエストでの SNI の必須化

非推奨: 2024年10月29日 サポート終了: 2025年4月29日 Auth0 サービスでは、すべての HTTPS リクエストで Server Name Indication (SNI) の使用が必須となります。SNI は TLS プロトコルの拡張機能で、クライアントがハンドシェイクの開始時に接続先のホスト名を示せるようにするものです。 提供開始以来、Auth0 のプライベートクラウド環境の大半と一部の Public Cloud 環境では、SNI が必須でした。たとえば、CA-1、JP-1、UK-1 の Public Cloud 環境では、常に SNI が必要でした。 この変更により、SNI の要件は残りの環境にも適用されます。環境ごとのスケジュールの詳細については、End-of-Life Rollout for Mandatory Use of SNI for HTTPS Requests を参照してください。

​
Auth0 との通信には常に HTTPS を使用してください

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

​
Management API の移行: Create スコープ必須化に伴うロール割り当ての更新

非推奨: 2024年3月7日 サポート終了: 2024年9月10日 User-Roles エンドポイント (POST /api/v2/users/{id}/roles) の Management API スコープでは、create:role_members スコープが必要になります。これにより、このスコープが本来意図する権限をより適切に表せます。 以前は、read:roles スコープでユーザーにロールを割り当てることができました。

​
クロスオリジン認証を使用するアプリケーションの更新

非推奨: 2024年4月25日 サポート終了: 2024年10月10日 Auth0 で新規作成されるアプリケーションでは、クロスオリジン認証はデフォルトで無効になります。一部の Management API エンドポイント (Get Clients, Get Client by ID) の呼び出しでは、cross_origin_authentication を使用するよう変更する必要があります。

​
テナント管理者の Subscription Tickets へのアクセスを削除

非推奨: 2024年6月5日 サポート終了: 2024年8月5日 Auth0 Support Center 内の Subscription Tickets の閲覧アクセスが、2024年8月5日に変更されます。テナント全体で、すべてのユーザーが作成したすべてのサポートチケットを引き続き表示および管理するには、新しい Elevated Support Access ロールが必要です。 非推奨: 2023年12月7日 サポート終了: 2024年2月5日 パスワードリセットおよびメールアドレス確認のリンクは、今後テナントログに記録されません。これらのリンクは、パスワードリセットまたはメールアドレス確認の リクエストに対するレスポンスから取得できます。

​
ログイントランザクションの最長有効期間の短縮

非推奨: 2023年9月5日 (Public Cloud) 、2023年11月21日 (Private Cloud) サポート終了: 2024年2月21日 この変更により、リダイレクトベースのログインフローの有効期間は最大1時間に制限されます。完了までに1時間を超えるログインフローは、Universal Login と Classic Login の両方で期限切れになります。期限切れ後にエンドユーザーのブラウザーから後続の操作 (例: メールアドレス/パスワードの入力、Actions/Rules へのリダイレクトの戻りなど) を行うと、次のいずれかになります。
  • フローを新しいログイントランザクションとして再開するため、関連付けられたアプリケーションのデフォルトのログインルートにリダイレクトされる
  • デフォルトのログインルートが設定されていない場合は、エラーページが表示される

​
リフレッシュトークン内の未登録スコープの非推奨

非推奨: 2023年7月12日 サポート終了: 2024年1月17日 未登録のスコープがリクエストされないようにするため、交換時のスコープ評価を改善しています。aud または audience の値 (テナントに登録されている API のもの) に対して登録されていないカスタムスコープ値は、未登録スコープと見なされます。 この変更により、API のスコープ評価には、ユーザー認証時にリクエストされたカスタムスコープや、Rules などの拡張機能を通じて追加されたカスタムスコープも含まれるようになります。この評価では、すべてのスコープが登録済みであることを検証し、未登録のものがある場合はエラーを返します。

​
auth0-cordova、angular-auth0、express-oauth2-bearer リポジトリの非推奨

非推奨: 2023年4月27日 サポート終了: 2023年6月30日 (express-oauth2-bearer) 、2023年10月27日 (angular-auth0 および auth0-cordova) 以下のリポジトリは非推奨になりました。 これらのライブラリは今後サポートされなくなります。該当日までに、アクティブなプロジェクトからこれらのライブラリを削除してください。 ご不明な点や懸念事項がある場合は、GitHub でお問い合わせください。

​
Actions の Node.js 16 から Node.js 18 への移行

移行予定日: 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 へ更新することを強くお勧めします。

​
拡張機能における edge.js のサポート

非推奨: 2022年12月21日 サポート終了: 2023年6月21日 2023年6月21日以降、Auth0 では拡張機能で Node.js から .NET や C# を実行することはサポートされなくなります。Auth0 はこれまで、edge.js という Node.js モジュールを通じて、Rules、Hooks、Custom Database Scripts 向けの拡張機能コードを記述するために、C# 言語のサブセットをサポートしていました。 拡張機能で Node.js から .NET や C# を実行するサポートを廃止することは、信頼できないコードを実行するプラットフォームのパフォーマンスとセキュリティを維持するうえで重要です。この変更により、次世代の拡張機能の提供内容を引き続き改善できるようになります。 詳細については、edge.js extensibility features からの移行を参照してください。

​
拡張機能における oracledb のサポート

非推奨: 2022 年 12 月 21 日 サポート終了: 2023 年 6 月 21 日 Auth0 は、2023 年 7 月 31 日以降、SharePoint 2010/2013 向けの auth0-claims-provider アドオンのサポートを終了します。 2023 年 6 月 21 日以降、Auth0 は拡張機能で Node.js から Oracle Database に接続する機能をサポートしなくなります。これまで Auth0 は、oracledb という Node.js モジュールを使用して、Rules、Hooks、Custom Database スクリプトの拡張機能コードから Oracle Database に接続することをサポートしていました。 拡張機能における Node.js から Oracle Database への接続サポートの廃止は、信頼されていないコードを実行するプラットフォームのパフォーマンスとセキュリティを維持するうえで重要です。この変更により、次世代の拡張機能機能の改善を継続できます。 詳細については、oracledb 拡張機能機能からの移行 を参照してください。

​
SharePoint 2010 / 2013 向け Auth0 Claims Provider

非推奨: 2023年1月31日 サポート終了: 2023年7月31日 Auth0 は、2023年7月31日をもって、SharePoint 2010/2013 向け auth0-claims-provider アドオンのサポートを終了します。このアドオンがないと、Auth0 の接続で「SharePoint People Picker」を使用して SharePoint 2010/2013 のユーザーに権限を割り当てることはできません。 2023年7月31日までに、auth0-claims-provider アドオンとのすべての統合を削除する必要があります。この日付以降、auth0-claims-provider アドオンとの既存の統合は正常に機能しなくなり、アプリケーションのユーザーに影響を及ぼす可能性があります。

​
Get Role Users エンドポイントのチェックポイントページネーション

非推奨: 2022年11月9日 サポート終了: 2023年5月9日 パフォーマンス向上のため、Management API の Get Role Users エンドポイントで合計1,000件を超える結果を返すには、チェックポイントページネーション方式を使用する必要があります。このページネーション方式は、大量の結果を扱えるよう最適化されています。オフセットページネーション方式では、結果は1,000件までに制限されます。 2つのページネーション方式の実装の詳細については、Get Role Users エンドポイントの Management API ドキュメントを参照してください。

​
レガシー カスタムクレーム

非推奨: 2022年7月28日 (Public Cloud) 、2022年8月31日 (Private Cloud) サポート終了: 2023年1月30日 (Public Cloud) 、2023年4月18日 (Private Cloud) 2023年1月30日以降のPublic Cloudおよび2023年4月18日以降のPrivate Cloudでは、Auth0 Actions を使用する場合と、Authentication API の/userinfoエンドポイントからのレスポンスにおいて、トークンに名前空間なしのカスタムクレームを追加できるようになります。これまでAuth0では、拡張機能コード (Rules / Hooks / Actions) を介して、アクセストークンおよびに名前空間付きクレームを追加できました。カスタムクレームへの移行により、プライベートな名前空間なしのカスタムクレームとOIDCユーザープロフィールクレームをに追加できるようになります。IDトークンは現在ユーザープロフィールクレームをサポートしており、さらにプライベートな名前空間なしのカスタムクレームもサポートするようになります。これらのクレームは、Auth0の/userinfoレスポンスにも追加されます。移行を開始するには、カスタムクレーム移行ガイドを参照してください。 テナントで、名前空間なしのカスタムクレームを設定しようとする拡張機能コード (Rules / Hooks / Actions) を実行しており、この非推奨化まではそれらのクレームが無視されていた場合は、それらのクレームがトークンおよび/userinfoレスポンスに含まれるようになります。設定とAuth0ログを確認することをお勧めします。 名前空間なしのプライベートクレームの追加に伴い、Auth0はテナントに影響する可能性がある以下の制限を適用します。
  • Auth0は、カスタムクレームのペイロードを最大100KBに制限します。
  • Auth0は、標準クレーム、またはAuth0内部で使用されるクレームのカスタマイズや変更を制限します。
  • 今後、Auth0は上記の一覧に含まれていない他のクレームの使用を制限する可能性があります。その場合、顧客には移行のための十分な期間を設けたうえで通知します。
  • Auth0は、/userinfoエンドポイントを除き、Auth0のを持つアクセストークンに対して、プライベートな名前空間なしのカスタムクレームの作成を制限します。
  • アクセストークンに追加できるのは、指定されたOIDCユーザープロフィールクレームのみです。
  • Auth0は、$文字で始まるカスタムクレームの作成を制限します。
カスタムクレームの詳細については、カスタムクレームを作成するを確認してください。

​
レガシー Private Cloud プラットフォーム

非推奨: 2022年6月13日 サポート終了: 2023年1月31日 Auth0 Private Cloud を支える基盤インフラを改善するため、最新の Kubernetes ベースの技術スタックの導入に加え、データベースのアップグレードも進めています。現在、すべての Auth0 Private Cloud のお客様と連携し、今年中に各 private cloud deployment を新しいインフラストラクチャスタックへアップグレードする日程を調整しています。また、旧スタックは 2023年1月31日をもって廃止されます。 さらに、2205 (2022年5月リリース) は、レガシー Private Cloud プラットフォーム向けの最後の正式リリースです。バグやセキュリティ脆弱性については、必要に応じて評価し、パッチリリースで対処します。  新しいインフラストラクチャスタックへアップグレードする前に、各環境を、アップグレードに対応する最小互換バージョンへ更新する必要があります。 ご不明な点がございましたら、Technical Account Manager までお問い合わせください。

​
ログ拡張機能

非推奨: 2022年5月4日 (Public Cloud) 、2022年6月9日 (Private Cloud release 2205) サポート終了: 2023年5月2日 (Public Cloud) 、2023年1月6日 (Private Cloud) Public Cloud では2022年5月4日から、Private Cloud では2022年6月9日から、以下の Auth0 Log Extensions は非推奨となります。
  • 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月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 Log Extensions は非推奨となります。
  • Logs to Segment
  • Logs to Mixpanel
  • Logs to AppInsights
  • Logs to Azure Blob Storage
上記の Log Extensions はすべて現在非推奨です。Auth0 Marketplace のログイベントストリームまたは統合を使用して、同等の機能を設定できます。Public Cloud では2022年11月2日、Private Cloud では2022年12月21日をもって、Auth0 は上記一覧のインストール済みログ拡張機能のサポートを終了します。詳細については、Log Extensions から移行するを参照してください。

​
テナント ホスト名の検証

非推奨: 2021 年 12 月 9 日および 2021 年 12 月 (Private Cloud Release 2112.2) サポート終了: 2022 年 6 月 9 日および 2022 年 9 月 9 日 (Private Cloud) Auth0 は、Public Cloud では 2022 年 6 月 9 日から、Private Cloud では 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> (エンタープライズ接続のプロビジョニング エンドポイント)
詳細については、Tenant Hostname Validation Migration を参照してください。

​
Node.js 16 への移行

サポート終了日: 2022年4月30日 2022年4月30日、Node.js v12 の長期サポート (LTS) が終了しました。これは、Node.js 開発チームがこのバージョンに対する重要なセキュリティ修正をバックポートしなくなったことを意味します。その結果、拡張機能コードがセキュリティ脆弱性にさらされる可能性があります。そのため、Auth0 は Node 12 から Node 16 への移行を進めています。 Node 16 への更新によって Node.js 標準ライブラリに破壊的変更が加わることはありませんが (影響を受けるのは Rules と Custom Database Action スクリプトです。詳しくは 破壊的変更 - Rules と Custom Database Action スクリプトのみ セクションを参照してください) 、セキュリティおよびコンプライアンスの観点から、Node バージョン 12 を使用しているお客様には、Active Long-Term Support (LTS) の Node バージョンを継続して利用することを推奨します。引き続き Node 8 を使用しているお客様は、すでにセキュリティコンプライアンスの対象外となっており、セキュリティリスクを解消するために Node 16 へ移行する必要があります。Auth0 は、Public Cloud テナント向けには 2022年2月22日に Node 8 ランタイムを削除し、Private Cloud では 2022年4月のリリースで削除しました。これらの日付以降も Node 8 に設定されたままのテナントでは、サービスが中断するリスクがあります。

​
不透明なアクセストークンと認可コードの固定長

非推奨: 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月以降、クライアントが認可コードやアクセストークンの値の長さを前提にしないよう、OAuth specification RFC6749 に準拠して、アクセストークンと認可コードは可変長で発行されます。現在、アクセストークンと認可コードの長さは固定です。現在の認可コードの長さは、一部のセキュリティ専門家が推奨する長さより短くなっています。この変更により、Auth0 はより強力な認可コードとトークンを提供するとともに、Auth0 システムのパフォーマンスも向上させます。 特定の長さの認可コードやアクセストークンに依存するよう構成されたシステムをご利用のお客様は、Public Cloud では2022年4月12日までに、Private Cloud では2022年6月30日のリリースまでに、固定長の構成から可変長の構成に変更する必要があります。

​
Node.js v8 拡張機能ランタイムのサポート終了

非推奨: 2020年4月15日 サポート終了: 2022年2月25日 (Public Cloud)、2022年4月 (Private Cloud リリース) 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 を使用しているすべてのお客様には、できるだけ早く、かつ 2022年4月30日に Node.js コミュニティによる Node 12 のサポートが正式に終了する前に、Node 16 を使用する Actions へ移行することを強く推奨します。必要な移行手順の詳細については、Rules と Hooks を Actions に移行するを参照してください。

​
レガシー Network Edge の非推奨化

非推奨: 2021年5月5日 (Public Cloud) サポート終了: 2021年11月3日 (Public Cloud) Auth0 のレガシー Network Edge は、Public Cloud では機能を停止します。2021年11月3日以降、新しい Auth0 Network Edge への移行を完了していない Public Cloud テナントには、トラフィックがルーティングされなくなります。新しい はすべて、自動的に新しい Network Edge 上に作成されます。

​
ページネーション未指定の Management API v2 リクエストの非推奨

非推奨: 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 はこの変更への準備に役立てられるよう、テナントログと移行用トグルを表示します。 影響を受けるのは、2020年7月21日より前に作成され、影響対象のエンドポイントを実際に呼び出しており、かつ 2 件以上の結果を返す可能性があるクエリで per_page パラメーターを渡していない、すべての Public Cloud テナントです。2020年7月21日より後に作成されたテナント、影響対象のエンドポイントを使用していないテナント、影響対象のエンドポイントを使用していて per_page パラメーターを渡しているテナント、または常に 1 件の結果しか返さないクエリを実行しているテナントは影響を受けません。詳しくは、Management API v2 エンドポイントのページ分割クエリへの移行を参照してください。

​
Private Cloud カスタムドメインの非推奨

非推奨: 2021年6月17日 サポート終了: 2021年12月20日 すべての Auth0 デプロイメントで一貫性を確保し、Auth0 のカスタムドメイン機能の強化に注力するため、2021年12月20日をもって Private Cloud のカスタムドメイン機能の提供を終了します。一貫性を確保することで、機能強化や信頼性の問題への対応をより迅速に進められるようになり、運用効率の向上と、お客様によるカスタムドメインの価値実現の早期化につながります。

​
ログアウト リダイレクトの検証

非推奨: 2021年5月25日 サポート終了: 2021年12月01日 2021年12月01日以降、ログアウト時の動作が変更され、ログアウトの実行中にから/login/callbackに渡されるreturnToクエリ パラメーターは使用されなくなり、代わりに Auth0 のログアウト API に渡された URI に常にユーザーがリダイレクトされるようになります。Auth0 にこれらの API のいずれかが事前に呼び出された記録がない場合、ログアウト自体は完了しますが、リダイレクトは行われず、エンドユーザーにはエラー ページが表示されます。詳細については、Logout Redirects Migration Guideを参照してください。

​
Application Admin Dashboard ロールの非推奨化

非推奨: 2021年2月1日 サポート終了: 2021年9月30日 (Public Cloud)、2021年9月 (Private Cloud 月次リリース) 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 を参照してください。

​
レガシー TLS の非推奨化

非推奨: 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 以降にアップグレードする必要があります。具体的な内容や必要な手順は、アプリケーションによって異なります。

​
Auth0-analytics.js の非推奨化

非推奨: 2018年1月 サポート終了: 2021年1月 Auth0 は、Lock に Facebook および Google Analytics との統合を追加する auth0-analytics.js ライブラリ の使用を非推奨としました。このライブラリは Lock のイベントを監視し、それらを Auth0-tag-manager.js ライブラリに渡します。レガシーな一部のケースでは、引き続き機能する可能性があります。このライブラリは現在メンテナンスされていません。Facebook、X、Google などのサードパーティ製アナリティクスライブラリへのプロキシリクエストを管理するために、auth0-tag-manage.js を使用するカスタムコードを作成する必要がある場合があります。

​
user_id を含まないデバイス認証情報メタデータの非推奨化

非推奨: 2020年8月31日 サポート終了: 2020年12月17日 Auth0 では現在、GET /api/v2/device-credentials エンドポイント を使用する際に user_id の指定が必須です。リクエストに user_id が含まれていない場合は、400 ステータスコードが返されます。この非推奨化の影響を受けるかどうかを確認するには、テナントログの depnote を確認してください。詳細については、非推奨エラーを確認する を参照してください。 Auth0 は、この非推奨化の影響を受けるテナントを特定し、それらのテナントの管理者に連絡しました。現在、お使いのテナントで user_id を含めずにリクエストしている場合は、できるだけ早く修正してください。

​
Azure AD/ADFS のメールアドレス確認の非推奨化

非推奨:
  • Public Cloud: 2020年11月18日
  • Private Cloud: 2020年12月1日
サポート終了:
  • Public Cloud: 2021年5月18日
  • Private Cloud: 2021年6月の Private Cloud Release (v2106)
Auth0 は以前、Azure AD および ADFS 接続で email_verified フィールドを true に設定していました。この非推奨日より前から Azure AD/ADFS 接続を使用していた場合は、メールアドレス確認の接続設定を上書きして以前の動作を維持するテナント設定が適用されています。 Public Cloud では 2021年5月18日から、Private Cloud では 2021年6月の Private Cloud Release (v2106) から、Auth0 はすべての Azure AD/ADFS 接続で接続レベルのプロパティを使用するようになります。それまでに、すべての接続が適切に設定されていることを確認してください。詳細については、Azure AD and ADFS のメールアドレス確認 を参照してください。 適用開始日: 2020年2月 Google Chrome v80 では、cookie の扱いが変更されます。これに伴い、Auth0 では cookie の扱いについて次の変更を実装します。
  • samesite 属性が設定されていない cookie は、lax に設定されます
  • sameSite=none が設定された cookie にはセキュリティ保護が必要です。そうでない場合、ブラウザーの cookie jar に保存できません
これらの変更の目的は、セキュリティを向上させ、CSRF 攻撃のリスク軽減に役立てることです。詳細については、sameSite Cookie Attribute Changes を参照してください。

​
User Search v2 の非推奨

非推奨: 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 のエンドポイントは 2021 年 5 月の Private Cloud 月次リリース以降利用できなくなり、新しい User Search v3 エンドポイントに置き換えられました。

​
機密アプリケーションからのパスワードレス エンドポイントの非推奨

Auth0 は、呼び出しがアプリケーションを代理して行われていることを Auth0 が認証できない場合、機密アプリケーションからの /passwordless/start エンドポイントの使用を非推奨としました。詳細については、機密アプリケーションからのパスワードレス エンドポイントへの移行 を参照してください。 に対するクリックジャッキング対策の変更 クリックジャッキングを防ぐため、ログインページを iframe でレンダリングする場合に追加できるヘッダーのオプトイン設定が Auth0 により追加されました。この設定を有効にすることを強く推奨します。詳細については、Universal Login のクリックジャッキング対策の変更 を参照してください。

​
IDトークン認証情報を使用する Management API エンドポイントの非推奨

非推奨: 2018年3月31日 サポート終了: TBD Auth0 は、一部の users エンドポイントおよび device エンドポイントの呼び出しに認証情報として IDトークン を使用する方法を非推奨とし、代わりにアクセストークンを使用するよう変更しています。詳細については、アクセストークンを使用する Management API エンドポイントへの移行 および アクセストークンを使用したユーザーアカウントのリンクへの移行 を参照してください。

​
Resource Owner Password /oauth/ro の非推奨

非推奨: 2017年7月8日 サポート終了: TBD 2017年7月8日をもって、Auth0 はパスワード接続と 接続の両方で /oauth/ro エンドポイントを非推奨としました。現在は、/oauth/token エンドポイントを使用して同じ機能を実装できます。詳細については、Resource Owner Password Flow Migration を参照してください。

​
Management API v1 の非推奨

非推奨: 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 を含まない最初のリリースとなります。サービスの中断を防ぐため、その日までに対応が必要になる場合があります。この移行の完了が必要なお客様には、これまでも通知を送付しており、今後も継続して送付します。

​
Instagram 接続の非推奨

非推奨: 2020年3月5日 サポート終了: 2020年3月31日 Facebook は、2020年3月31日をもって Instagram のレガシー API を停止し、Instagram ログインを実装するための代替手段は提供しないと発表しました。詳細については、Instagram 接続の非推奨 を参照してください。

​
Yahoo API の変更

非推奨: 2020年3月1日 サポート終了: 2020年3月1日 Yahoo では、ユーザープロフィールの取得方法と、そこに含まれる情報が変更されました。詳細については、Yahoo API Changes を参照してください。

​
Google Cloud Messaging の非推奨

非推奨: 2019年4月11日 サポート終了: 2019年4月11日 2019年4月11日付けで、Google は Google Cloud Messaging (GCM) を非推奨とし、Firebase Cloud Messaging (FCM) に置き換えました。詳細については、Google to Firebase Cloud Messaging Migration を参照してください。

​
Facebook Social Context フィールドの非推奨

非推奨: 2019年4月30日 サポート終了: 2019年7月30日 2019年4月30日、Facebook は新規アプリケーションにおける Social Context フィールドの使用を非推奨にしました。詳細については、Facebook Social Context Field Deprecation を参照してください。

​
Facebook Graph API の変更

非推奨: 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 を参照してください。詳細については、Facebook Graph API Changes を参照してください。

​
Lock v11 and Auth0.js v9

Auth0 では、サービスのセキュリティを継続的に強化しています。その一環として、/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 からの移行がまだ完了していない場合、ユーザーにサービス停止、ログイン失敗、その他の不具合が発生する可能性があります。通常の機能を復旧するには、移行を完了する必要があります。非推奨に関連するテナントログ内のエラーの原因を特定するには、deprecation errors を確認してください。

​
影響を受ける機能

現在、アプリケーションで Lock v8、v9、v10 または Auth0.js v6、v7、v8 を使用してログインを実装している場合は、この変更の影響を受けます。さらに、アプリケーションが API 経由で /usernamepassword/login または /ssodata エンドポイントを直接呼び出している場合も、影響を受けます。 Universal Login を使用しているアプリケーションについては、ログインページ内で使用しているライブラリのバージョンを更新することを推奨します。 ただし、アプリケーションに Lock または Auth0.js を埋め込んで使用している場合や、影響を受ける API エンドポイントを直接呼び出している場合は、更新が必須です。また、引き続き非推奨のエンドポイントを使用しているアプリケーションは、サービス終了日以降、正常に動作しなくなります。 ここで明示的に挙げられていないライブラリおよび SDK は、この移行の影響を受けません。

​
テナントログ検索 v2 の非推奨

非推奨: 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 へ移行しており、影響を受ける可能性があるお客様には、案内された猶予期間中に v3 へオプトインするよう通知しています。詳細については、Tenant Log Search v1 から v2 への移行 を参照してください。

​
オーストラリアの許可リスト登録用の新しい IP アドレス

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

​
影響を受ける機能

お使いの環境に接続するカスタム データベース接続、Rule、またはカスタム メールプロバイダーを使用しており、かつ 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

​
ヨーロッパで許可リストに追加する新しい IP アドレス

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

​
影響を受ける機能

ご利用の環境に接続するカスタムデータベース接続、Rule、カスタムメールプロバイダーのいずれかを使用しており、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

​
欧州およびオーストラリア環境における CDN プロバイダーの移行

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

​
影響を受ける機能

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

​
パスワード交換およびリフレッシュトークン交換に関する Rules の移行

2017年5月31日、セキュリティ向上に向けたAuth0の取り組みの一環として、 Password Grant exchange (password exchange) とリフレッシュトークン交換でも Rules を実行できるようにしました。

​
影響を受ける機能

この機能を使用しているのは、Authentication API の /oauth/token エンドポイントを grant_type = "password"、grant_type = "http://auth0.com/oauth/grant-type/password-realm"、または grant_type = "refresh_token" で呼び出している場合です。 現在これらの交換を使用しており、Dashboard で Rules を定義している場合は、影響を受ける可能性があります。円滑に移行できるようにするため、Auth0 ではお使いのテナントについて、これらの特定の交換で Rules が実行されないようにしています。今後、これらの Rules は新規のお客様と、まだこれらの交換を使用していないお客様に対して実行されます。 context.protocol プロパティを確認することで、これらの交換に対する動作を変更するロジックを Rules に追加できます。
  • oauth2-password は password (および password-realm) 交換を示します
  • oauth2-refresh-token はリフレッシュトークン交換を示します
必須のオプトイン日より前に、このテナントで新しい動作を有効にしてテストする場合は、Dashboard にログインし、Tenant Settings > Advanced で Run Rules on Password and Refresh Token Exchanges トグルを有効にしてください。

​
アカウントリンクの廃止

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

​
影響を受ける機能

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

​
許可リストに追加する IP アドレス範囲

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

​
影響を受ける機能

お使いの環境に接続されたカスタムデータベース接続、Rule、および/またはカスタムメールプロバイダーを使用しており、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 以降にアップグレードすることを強く推奨します。
Lock を使用していない場合でも、この脆弱なリセットフローには API 経由で直接アクセスできます。 (詳細については、/dbconnections/change_password エンドポイントを参照してください。) Auth0 は、現在のフローを使用しているすべてのアプリを、直ちに新しいリセットフローへ移行し、この移行を有効にすることを強く推奨しています。

​
Rule からのリダイレクトでは state パラメーターが必須

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

​
影響を受ける機能

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

​
すべてのユーザーを削除するエンドポイントの変更

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

​
影響を受ける機能

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

​
メール配信テンプレートのカスタマイズに関する変更

2016年8月29日以降、Auth0 の組み込みメールプロバイダーは本番環境での使用がサポート対象外となります。Auth0 のプロバイダー経由で送信されるメールは、今後カスタマイズできなくなります。これらのメールは固定テンプレートのみとなり、送信元アドレスや件名は変更できません。 組み込みメールサービスは引き続きテスト目的で使用できますが、アプリを本番環境に移行する前に、Auth0 がサポートするサードパーティサービス (Amazon SES、Mailchimp、SendGrid、またはその他の SMTP ベースのプロバイダー) に切り替える必要があります。すでにカスタムメールプロバイダーを使用している場合は、対応は不要です。

​
ユーザープロフィールと IDトークンから IDプロバイダーのアクセストークンを削除

2016 年 8 月 8 日以降、Auth0 Authentication API から返されるユーザープロフィール JSON オブジェクト (IDトークン) の形式が変更され、ユーザープロフィールの identities 配列に含まれていた IDプロバイダーのアクセストークンが削除されました。 ユーザーの IDプロバイダーのアクセストークンを取得するには、read:user_idp_tokens スコープで生成された API トークンを含めて、/api/v2/users/{user-id} エンドポイントに対して HTTP GET リクエストを実行する必要があります。Auth0 Rules の user 引数では、引き続き IDプロバイダーのアクセストークンにアクセスできます。

​
影響を受ける機能

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

​
Tokeninfo エンドポイントの検証

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) からすべてのメールを送信するようになりました。カスタムメールプロバイダーは現在無料で利用できます。「From」アドレスをカスタマイズするには、Auth0 がサポートするサードパーティサービス (Amazon SES、Mailchimp、SendGrid) またはその他の SMTP ベースのプロバイダーに切り替えることができます。すでにカスタムメールプロバイダーを使用している場合は、変更はありません。

​
PATCH および POST エンドポイントでは secret_encoded フラグを受け付けなくなりました

PATCH および POST のアプリケーション エンドポイントでは、jwt_configuration.secret_encoded 設定は受け付けられなくなりました。 OIDC 仕様への準拠をさらに進めるため、Auth0 は新規アプリケーションに対して、base64 でエンコードされたアプリケーションシークレットを生成または受け付けなくなります。 エンコードされたシークレットが保存されている既存のアプリケーションは、そのまま維持され変更されませんが、新規アプリケーションでは base64 エンコーディングは使用されなくなります。そのため、secret_encoded フラグは受け付けられず、不要になりました。

​
影響を受ける機能

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