以下は、すべてのお客様ですでに有効になっている移行です。ご不明な点がございましたら、Support Center からチケットを作成してください。
非カスタムソーシャル接続における保護対象プロパティ 非推奨 : 2024年7月30日サポート終了 : 2025年1月31日接続に関するManagement APIエンドポイント (GET、POST、PATCH) では、非カスタムソーシャル接続のoptionsオブジェクトにおいて、以下の保護対象プロパティの値を取得または設定できなくなります。
authorizationURLtokenURLuserInfoUrlbaseUrluserAuthorizationURLgrant_typeauthorizationURLtokenURLuserInfoUrlbaseUrluserAuthorizationURLgrant_type
非カスタムソーシャル接続とは、実装ロジックがすべてAuth0サービス内で管理されているソーシャル接続を指します。このカテゴリには、カスタムソーシャルコネクタとして明示的に作成された接続や、カスタムソーシャル接続機能に依存するMarketplaceインテグレーションとして提供される接続は含まれません。
Management API でユーザーを更新した後に意図せずセッションが削除される問題 非推奨 : 2025年2月11日サポート終了 : 2025年8月19日Management API Update a user エンドポイント (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 プロトコルの拡張機能で、ハンドシェイク処理の開始時に、接続先のホスト名をクライアントが示せるようにするものです。
作成当初から、当社のプライベートクラウド環境の大半と一部のパブリッククラウド環境では、SNI が必須とされてきました。たとえば、CA-1、JP-1、UK-1 のパブリッククラウド環境では、常に 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:role_members スコープ が必要になります 非推奨 : 2024年3月7日サポート終了 : 2024年9月10日User-Roles endpoint (POST /api/v2/users/{id}/roles) 用の Management API scopes には、create:role_members スコープ が必要になります。これにより、その スコープ が意図する permissions をより適切に反映できるようになります。
これまでは、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日今後、パスワードリセットリンクおよびメール確認リンクはテナントログに記録されなくなります。これらのリンクは、パスワードリセットまたはメール確認のManagement API
非推奨 : 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 へアップデートすることを強くお勧めします。
Extensibility 機能における edge.js のサポート 非推奨: 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 からの移行 をご覧ください。
Extensibility 機能 での oracledb のサポート 非推奨: 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 という Node.js モジュールを使用して、Rules、Hooks、Custom Database Scripts の extensibility コードから Oracle Database に接続できるようサポートしてきました。
Extensibility における Node.js から Oracle Database への接続サポートの廃止は、信頼できないコードを実行するための高性能で安全なプラットフォームを維持するうえで重要です。この変更により、次世代の Extensibility 機能を今後も継続的に改善していくことができます。
詳細については、oracledb extensibility features からの移行 をご覧ください。
Auth0 Claims Provider for SharePoint 2010 / 2013 非推奨: 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 アドオンとの既存の連携は正常に機能しなくなり、アプリケーションのユーザーに影響が及ぶ可能性があります。
非推奨: 2022年11月9日サポート終了: 2023年5月9日パフォーマンス向上のため、Get Role Users Management API エンドポイントで合計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)Auth0 は、Public Cloud では 2023年1月30日から、Private Cloud では 2023年4月18日から、Auth0 Actions および Authentication API の /userinfo エンドポイントのレスポンスで、JWT Rules / Hooks / Actions ) を通じて、アクセストークンおよび ID tokens access tokens /userinfo レスポンスにも追加されます。移行を開始するには、Custom Claims Migration Guide をご覧ください。
テナントで、これまでこの非推奨化により無視されていた名前空間のないカスタムクレームを設定しようとする拡張コード (Rules / Hooks / Actions ) を実行している場合、それらのクレームがトークンおよび /userinfo レスポンスに含まれるようになります。設定と Auth0 のログを確認することをお勧めします。
名前空間のない非公開クレームの追加に伴い、Auth0 はテナントに影響する可能性がある以下の制限を適用します。
Auth0 は、カスタムクレームのペイロードを最大 100KB に制限します。
Auth0 は、OPENID
今後、Auth0 は上記一覧に含まれていない他のクレームの使用を制限する可能性があります。その場合は、移行のための十分な期間を設けたうえでお客様に通知します。
Auth0 は、/userinfo エンドポイントを除き、Auth0 の audience
アクセストークンに追加できるのは、指定された OIDC ユーザープロファイルクレームのみです。
Auth0 は、$ 文字で始まるカスタムクレームの作成を制限します。
カスタムクレームの詳細については、Create Custom Claims をご覧ください。
非推奨: 2022年6月13日サポート終了: 2023年1月31日Auth0 Private Cloud を支える基盤インフラストラクチャの改善の一環として、最新の Kubernetes ベースの技術スタックの導入とデータベースのアップグレードを進めています。現在、すべての Auth0 Private Cloud のお客様と連携し、今年中に各プライベートクラウド環境を新しいインフラストラクチャスタックへアップグレードできるよう、日程を調整しています。これに伴い、旧スタックは 2023年1月31日をもって廃止されます。
また、2205 (2022年5月リリース) は、旧 Private Cloud プラットフォーム向けの最後の正式リリースです。バグやセキュリティ脆弱性については、必要に応じて評価し、パッチリリースで対応します。新しいインフラストラクチャスタックへのアップグレードに先立ち、各環境をアップグレードに対応可能な最小互換バージョンまで更新する必要があります。
ご不明な点がございましたら、担当の Technical Account Manager までお問い合わせください。
非推奨: 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 のログイベントストリームまたはインテグレーションを利用することで、同等の機能を設定できます。Public Cloud では2022年11月2日、Private Cloud では2022年12月21日をもって、Auth0 は上記一覧にあるインストール済みのログ拡張機能のサポートを終了します。詳細については、Migrate from Log Extensions を参照してください。
非推奨 : 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 をご覧ください。
サポート終了 : 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 Scripts は影響を受けます。詳しくは Breaking changes - Rules and Custom Database Action Scripts 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 に設定されたままのテナントでは、サービスが中断するリスクがあります。
Opaque Access Token と認可コードの固定長 非推奨 : 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 に準拠するため、Access Token と認可コードは可変長で発行されます。現在、Access Token と認可コードの長さは固定です。現在の認可コードの長さは、一部のセキュリティ専門家の推奨よりも短くなっています。この変更により、Auth0 はより強固なコードとトークンを提供すると同時に、Auth0 システムのパフォーマンスも向上させます。
特定の長さの認可コードおよび Access Token に依存するよう構成されたシステムをご利用のお客様は、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 への移行 をご覧ください。
非推奨 : 2021年5月5日 (Public Cloud)サポート終了 : 2021年11月3日 (Public Cloud)Auth0 の従来のネットワークエッジは、Public Cloud で機能しなくなります。2021年11月3日以降、新しい Auth0 ネットワークエッジへの移行を完了していない Public Cloud テナントには、トラフィックが送られなくなります。新しい カスタムドメイン
ページネーションされていない 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日より前に作成され、かつ、複数の結果を返す可能性があるクエリで per_page パラメーターを指定せずに、対象のエンドポイントを継続的に呼び出しているすべての Public Cloud テナントです。一方、2020年7月21日以降に作成されたテナント、対象のエンドポイントを使用していないテナント、対象のエンドポイントを使用していて per_page パラメーターを指定しているテナント、または常に1件の結果しか返さないクエリを実行しているテナントは影響を受けません。詳しくは、Management API v2 エンドポイントのページネーション付きクエリへの移行 をご覧ください。
Private Cloud カスタムドメインの廃止 非推奨 : 2021年6月17日サポート終了 : 2021年12月20日すべての Auth0 デプロイ環境で一貫性を保ち、Auth0 の Custom Domain 機能の強化に注力するため、2021年12月20日をもって Private Cloud Custom Domain 機能の提供を終了します。一貫性を確保することで、機能強化や信頼性に関する問題への対応をより迅速に進められるようになり、運用効率の向上と、お客様によるカスタムドメイン活用の早期化につながります。
非推奨 : 2021年5月25日サポート終了日 : 2021年12月1日2021年12月1日以降、ログアウト時の動作が変更され、ログアウトの実行中に Identity Providers /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 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 を参照してください。
非推奨 : 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 以降にアップグレードする必要があります。必要な詳細や手順は、アプリケーションによって異なります。
非推奨 : 2018年1月サポート終了 : 2021年1月Auth0 は、Lock に Facebook と Google Analytics の連携を追加する auth0-analytics.js library の使用を非推奨としました。このライブラリは Lock のイベントを監視し、それらを Auth0-tag-manager.js ライブラリに渡します。従来の環境では、一部のケースで引き続き動作する可能性があります。このライブラリは現在メンテナンスされていません。Facebook、X、Google などのサードパーティ分析ライブラリへのプロキシリクエストを管理するために、auth0-tag-manage.js を使用するカスタムコードの作成が必要になる場合があります。
非推奨 : 2020年8月31日サポート終了 : 2020年12月17日Auth0 では現在、GET /api/v2/device-credentials エンドポイント を使用する際に user_id の指定が必須となっています。リクエストに user_id が含まれていない場合は、400 ステータスコードが返されます。この廃止の影響を受けるかどうかは、テナントのログにある depnote を確認してください。
Auth0 は、この廃止の影響を受けるテナントを特定し、それらのテナントの管理者に連絡しました。現在お使いのテナントで user_id なしのリクエストを送信している場合は、できるだけ早く対応してください。
非推奨 :
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 を参照してください。
適用開始 : 2020年2月Google Chrome v80 では、Cookie の処理方法が変更されます。これに伴い、Auth0 でも Cookie の取り扱いに関して以下の変更を実施します。
samesite 属性が設定されていない Cookie は、lax として設定されますsameSite=none が設定された Cookie はセキュアである必要があり、そうでない場合はブラウザーの Cookie jar に保存できません
これらの変更は、セキュリティを向上させ、CSRF 攻撃の緩和に役立てることを目的としています。詳細については、sameSite Cookie 属性の変更 を参照してください。
非推奨 : 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 エンドポイントに置き換えられました。
Confidential Applications からの Passwordless エンドポイントの廃止 Auth0 は、呼び出しがそのアプリケーションに代わって行われていることを Auth0 が確認できない場合、confidential applications からの /passwordless/start エンドポイントの使用を廃止しました。詳しくは、Migrate to Passwordless Endpoint from Confidential Applications をご覧ください。Universal Login
クリックジャッキングを防ぐため、ログインページを iframe で表示する場合に備えて、Auth0 はヘッダーを追加するためのオプトイン設定を導入しました。これを有効にすることを強く推奨します。詳細は、Clickjacking Protection for Universal Login Change をご覧ください。
ID token認証情報を使用するManagement APIエンドポイントの非推奨化 非推奨 : 2018年3月31日サポート終了 : 未定Auth0では、一部のusersおよびdeviceエンドポイントの呼び出しにID tokenを認証情報として使用する方法が非推奨となり、代わりにaccess tokenを使用する方式に移行しています。詳細については、Migrate to Management API Endpoints with Access Tokens およびMigrate to Link User Accounts with Access Tokens を参照してください。
Resource Owner Password /oauth/ro の非推奨化 非推奨化 : 2017年7月08日提供終了 : TBD2017年7月08日をもって、Auth0 はパスワード接続および パスワードレス /oauth/ro エンドポイントを非推奨としました。現在は、/oauth/token エンドポイントを使用して同じ機能を実装できます。詳しくは、Resource Owner Password Flow Migration をご覧ください。
非推奨化 : 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 を含む最後のリリースとなります。サービスの中断を防ぐため、それまでに対応が必要になる場合があります。この移行を完了する必要があるお客様には、これまでも通知をお送りしており、今後も継続してお送りします。
非推奨 : 2020年3月5日提供終了 : 2020年3月31日Facebook は、2020年3月31日をもって Instagram のレガシー API を停止し、Instagram ログインを実装するための代替手段は提供しないと発表しました。詳細については、Instagram Connection Deprecation を参照してください。
非推奨 : 2020年3月1日提供終了 : 2020年3月1日Yahoo は、ユーザープロファイルの取得方法と、そこに含まれる情報を変更しました。詳細については、Yahoo API の変更 を参照してください。
Google Cloud Messaging の廃止 非推奨化 : 2019年4月11日提供終了 : 2019年4月11日2019年4月11日をもって、Google は Google Cloud Messaging (GCM) を廃止し 、Firebase Cloud Messaging (FCM) に移行しました。詳細については、Google から Firebase Cloud Messaging への移行 を参照してください。
Facebook Social Context フィールドの非推奨化 非推奨化日 : 2019年4月30日提供終了日 : 2019年7月30日2019年4月30日、Facebook は新規アプリケーションでの Social Context フィールドの使用を非推奨としました。詳細については、Facebook Social Context Field Deprecation を参照してください。
非推奨 : 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 を参照してください。
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月に公表された CSRF 脆弱性は完全に軽減されました。これは、2018年7月16日に最初に案内したソフトリムーバルの猶予期間の終了も意味しており、Legacy Lock API は今後再び有効にできません。
Legacy Lock API への移行がまだ完了していない場合、ユーザーにサービス停止、ログイン失敗、またはその他の悪影響が発生する可能性があります。通常の機能を復旧するには、移行を完了する必要があります。非推奨化に関連するテナントログ内のエラーの発生元を特定するには、非推奨化エラーを確認してください。
現在、Lock v8、v9、v10、または Auth0.js v6、v7、v8 を使用してアプリケーションにログイン機能を実装している場合、この変更の影響を受けます。また、アプリケーションが API 経由で /usernamepassword/login または /ssodata エンドポイントを直接呼び出している場合も、影響を受けます。
Universal Login を使用しているアプリケーションについては、ログインページ内で使用しているライブラリのバージョンを更新することを推奨します。
ただし、アプリケーションに Lock または Auth0.js を埋め込んで使用している場合や、影響を受ける API エンドポイントを直接呼び出している場合は、更新が必須です。なお、廃止予定のエンドポイントを引き続き使用しているアプリケーションは、サービス終了日以降、正常に動作しなくなります。
ここで明示的に挙げられていないライブラリおよび SDK は、この移行の影響を受けません。
Tenant Log Search 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 へオプトインするよう通知しています。詳細については、Tenant Log Search v1 から v2 への移行 を参照してください。
オーストラリア向け許可リスト用の新しいIPアドレス 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ヨーロッパ向け許可リスト用の新しい IP アドレス 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欧州およびオーストラリア環境での CDN プロバイダー移行 2017年7月12日より、Auth0 は Auth0 CDN のスケーラビリティと可用性を向上させました。現在は Amazon CloudFront を使用しています。この変更はすでに米国環境で実施しており、欧州およびオーストラリアでも実施する準備が整いました。
ヨーロッパまたはオーストラリアで、当社のCDNでホストされている Lock を使用している場合、この変更の対象となります。この変更によってアプリケーションに中断や動作の変化が生じることはないため、特に対応は必要ありません。この通知は情報提供のみを目的としたものです。
パスワード交換およびリフレッシュトークン交換ルールの移行 2017年5月31日、セキュリティ強化に向けたAuth0の取り組みの一環として、OAuth 2.0 Resource Owner
この機能を使用しているのは、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 にログインし、Tenant Settings > Advanced で Run Rules on Password and Refresh Token Exchanges トグルを有効にしてください。
2017年3月1日、Auth0ではセキュリティの強化と標準準拠の向上の一環として、認可コールバック内でのアカウントリンクのサポートを終了しました (つまり、authorize呼び出しの一部としてアクセストークンを受け取ることを廃止しました) 。
この件に関するメール通知を受け取った場合は、この変更の影響を受けています。アカウントのリンクに Management API を使用するようアプリケーションの更新を進める際は、テナントのログで警告を確認することで、引き続き影響を受けているかどうかを確認できます。authorize 呼び出しでアクセストークンを送信している場合は、これらのエントリがログに記録されます。
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.422017年2月1日以前のAuth0のパスワードリセットフローでは、ユーザーはメールアドレスと新しいパスワードを入力できました。これにより、パスワードリセットをリクエストしたことを確認するよう求める確認メールがユーザーに送信されていました。
この問題では、確認リンクがユーザーによって誤ってクリックされると、攻撃者にユーザーのパスワードを変更されるおそれがあります。
Lock バージョン 9 以降では、新しいパスワードリセットフローのみを使用します。Lock 8 以前は、新しいパスワードリセットフローに対応していません。できるだけ早く Lock 9 以降にアップグレードすることを強く推奨します。
Lock を使用していない場合でも、この脆弱なリセットフローには API 経由で直接アクセスできます。 (詳細については、/dbconnections/change_password エンドポイント を参照してください。) Auth0 は、現在のフローを使用しているすべてのアプリを直ちに新しいリセットフローへ移行し、この移行を有効にすることを強く推奨しています。
ルールからのリダイレクトでは state パラメーターが必須 2016年12月6日以降、Auth0 ルールからリダイレクトが行われる場合、Auth0 は HTTP で state パラメーターを生成して送信し、フローが /continue エンドポイント に戻る際に、その state パラメーターが有効かどうかを確認します。リダイレクト先のサイトでは、state パラメーターの値を取得し、/continue エンドポイント に戻る際にその値をパラメーターとして付与して返す必要があります。
この変更の影響を受けるのは、ルール からリダイレクトしていて、かつ 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 ルールの user 引数では、引き続き ID プロバイダーのアクセストークンにアクセスできます。
この変更の影響を受けるのは、ルール外で Identity Provider のアクセストークン (ユーザープロファイル内の identities[0].access_token) を使用し、Identity Provider 経由で他のサービス (Facebook Graph API、Google APIs など) を呼び出している場合のみです。変更後に作成されたテナントには、この更新が自動的に適用されます。
2016年6月1日以降、Tokeninfo エンドポイントを呼び出す際は、API 呼び出しの URL (たとえば https://{yourDomain}/) が、検証する ID トークンの iss 属性の値と一致している必要があります。これらの値が一致しない場合、レスポンスは HTTP 400 - Bad Request となります。
Tokeninfo エンドポイントを直接呼び出している場合は、検証する ID Token の 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 フラグが受け付けられなくなりました jwt_configuration.secret_encoded 設定は、PATCH および POST の applications エンドポイントでは受け付けられなくなりました。OIDC 仕様への準拠をさらに強化するため、Auth0 は新しいアプリケーションに対して base64 エンコードされたアプリケーションシークレットを生成または受け付けなくなります。
エンコードされたシークレットが保存されている既存のアプリケーションはそのまま維持され、変更もありませんが、新しいアプリケーションでは base64 エンコーディングは使用されなくなります。その結果、secret_encoded フラグは不要となり、受け付けられなくなりました。
この変更の影響を受けるのは、これらのエンドポイントを直接利用している場合のみです。 
認証
ユーザー管理
カスタマイズ
プラットフォーム