> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev-fix-docs-5525.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > List of Auth0 updates that have already been enabled for all customers. # Past Migrations These are migrations that have already been enabled for all customers. If you have any questions, create a ticket in our [Support Center](https://support.auth0.com/center/s/). ## Protected Properties in Non-Custom Social Connections **Deprecated**: July 30, 2024 **End of life**: January 31, 2025 Management API endpoints for connections (`GET`, `POST`, and `PATCH`) will no longer allow retrieving or setting values for the following protected properties in the context of the `options` object for non-custom social connections: * `authorizationURL` * `tokenURL` * `userInfoUrl` * `baseUrl` * `userAuthorizationURL` * `grant_type` * `authorizationURL` * `tokenURL` * `userInfoUrl` * `baseUrl` * `userAuthorizationURL` * `grant_type` Non-custom social connections refer to any social connection whose implementation logic is controlled entirely within the Auth0 service itself. This category excludes any connections explicitly created as custom social connectors or those available as Marketplace integrations that rely on custom social connection functionality. ## Unwarranted Session Removal After Management API User Updates **Deprecated**: February 11, 2025 **End of life**: August 19, 2025 The Management API [Update a user](https://auth0.com/docs/api/management/v2/users/patch-users-by-id) endpoint (`PATCH /api/v2/users/{id}`) will no longer invalidate user sessions for database connection users when: * The `email` or `email_verified` attributes are set to an unchanged value. * The `email_verified` attribute is set to a `true` value. ## Mandatory Use of SNI for HTTPS requests **Deprecated**: October 29, 2024 **End of life**: April 29, 2025 The Auth0 service will mandate using [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication) (SNI) for all HTTPS requests. SNI is an extension to the TLS protocol that allows the client to indicate the hostname to which it intends to connect at the start of the handshake process. Since their creation, the vast majority of our private cloud environments and some of our public cloud environments have enforced the SNI requirement. For example, the CA-1, JP-1, and UK-1 public cloud environments always required SNI. With this change, the SNI requirement will apply to the remaining environments. For more detailed information on environment-specific timelines, read the [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) article. ## Always Use HTTPS for Communication with Auth0 **Deprecated**: September 4, 2024 **End of life**: October 4, 2024 Starting October 4, 2024, Auth0 will no longer automatically redirect API requests using unencrypted HTTP to secure HTTPS and will respond with an error. To avoid any disruption in service, update any HTTP URLs you use or publish to use HTTPS instead. ## Management API Transition: Updating Roles Assignment to Require Create Scope **Deprecated**: March 7, 2024 **End of life**: September 10, 2024 Management API scopes for the User-Roles endpoint (`POST /api/v2/users/{id}/roles`) will require the `create:role_members` scope. This better represents the scope's intended permissions. Previously, roles could be assigned to users with `read:roles` scope. ## Update Applications that use Cross-Origin Authentication **Deprecated**: April 25, 2024 **End of life**: October 10, 2024 New applications created in Auth0 will have cross-origin authentication disabled by default. Calls to some Management API endpoints ([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)) will need to be modified to use `cross_origin_authentication`. ## Remove Subscription Tickets access for Tenant Admins **Deprecated**: June 5, 2024 **End of life**: August 5, 2024 Access to view [Subscription Tickets](/docs/troubleshoot/customer-support/open-and-manage-support-tickets) within the Auth0 Support Center is changing on August 5, 2024. To retain access to view and manage all support tickets created by all users across a tenant, the new Elevated Support Access role is required. ## Password Reset and Email Verification Links in Tenant Logs Deprecation **Deprecated**: December 7, 2023 **End of life**: February 5, 2024 Password reset and email verification links will no longer be logged to tenant logs. These links can be retrieved from the password reset or email verification Management API request response. ## Reducing Maximum Expiration Time for Login Transactions **Deprecated**: September 5, 2023 (Public Cloud), November 21, 2023 (Private Cloud) **End of life**: February 21, 2024 With this change, we will enforce a maximum lifetime of 1 hour for redirection-based login flows. Login flows that take longer than 1 hour to complete will expire in both Universal and Classic Login. After expiration, subsequent actions from the end user’s browser (e.g. input email/password, redirect back to Actions/Rules, etc.) will result in either: * A redirect to the associated application’s default login route to reinitiate the flow as a new login transaction, or * An error page if the default login route is not configured. ## Unregistered Scopes in Refresh Tokens Deprecation **Deprecated**: July 12, 2023 **End of life**: January 17, 2024 We are improving scope evaluation during refresh token exchange to ensure that unregistered scopes cannot be requested. Custom scope values not registered against the `aud` or `audience` value (for an API registered in your tenant) are considered unregistered scopes. With this change, the API scope evaluation will include any custom scopes requested during user authentication or injected through extensibility, such as [Rules](/docs/customize/rules). This evaluation will validate that all scopes are registered, returning an error if any are not registered. ## auth0-cordova, angular-auth0, and express-oauth2-bearer Repo Deprecations **Deprecated**: April 27, 2023 **End of life**: June 30, 2023 (express-oauth2-bearer), October 27, 2023 (angular-auth0 and auth0-cordova) We have deprecated the following repos: * [express-oauth2-bearer](https://github.com/auth0/express-oauth2-bearer) | [migration guide](https://github.com/auth0/express-oauth2-bearer/blob/master/MIGRATION_GUIDE.md) * [angular-auth0](https://github.com/auth0/angular-auth0) | [migration guide](https://github.com/auth0/angular-auth0/blob/master/MIGRATION_GUIDE.md) * [auth0-cordova](https://github.com/auth0/auth0-cordova) | [migration guide](https://github.com/auth0/auth0-cordova/blob/master/MIGRATION_GUIDE.md) These libraries will no longer be supported. Please remove these libraries from any active projects before these dates. If you have any questions or concerns, please reach out to us on GitHub. ## Actions Migration from Node.js 16 to Node.js 18 **Target migration**: Sept 11, 2023 As part of our mission to support every future version of LTS Node.js through Actions, and to be in line with the Node JS developer community, we are releasing Node 18 while Node 16 is still in Active LTS. We urge all customers to transition today to Node 18 and make the most of its LTS. Remember, while Node 16 LTS remains available until September, their use may involve certain risks following the conclusion of LTS and we recommend you to update to Node 18. Node.js 18 is now generally available (GA) across our entire suite of extensibility offerings. This includes Actions, Rules, Hooks, Database Scripts, and Custom Social Connections. We strongly encourage everyone to update to Node 18 by Sept 11, 2023, to adhere to best code security practices. ## Support for edge.js in Extensibility Features **Deprecated:** December 21, 2022 **End of life:** June 21, 2023 After June 21, 2023, Auth0 will no longer support running .NET and C# from Node.js in Extensibility features. Auth0 previously supported a subset of the C# language to write extensibility code for Rules, Hooks, and Custom Database Scripts via a Node.js module called edge.js. Deprecating support for running .NET and C# from Node.js in Extensibility is critical to maintaining a performant and secure platform for running untrusted code. This change will allow us to continue improving our next-generation Extensibility offerings. To learn more, read [Migrate from edge.js extensibility features](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-from-edge-js-extensibility-features). ## Support for oracledb in Extensibility Features **Deprecated:** December 21, 2022 **End of life:** June 21, 2023 Auth0 will no longer support the auth0-claims-provider add-on for Sharepoint 2010/2013 after July 31, 2023. After June 21, 2023, Auth0 will no longer support connecting to Oracle Databases from Node.js in Extensibility features. Auth0 previously supported connecting to Oracle Databases from extensibility code for Rules, Hooks, and Custom Database Scripts via a Node.js module called [oracledb](https://www.npmjs.com/package/oracledb). Deprecating support for connecting to Oracle Databases from Node.js in Extensibility is critical to maintaining a performant and secure platform for running untrusted code. This change will allow us to continue improving our next-generation Extensibility offerings. To learn more, read [Migrate from oracledb extensibility features](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-from-oracledb-extensibility-features). ## Auth0 Claims Provider for SharePoint 2010 / 2013 **Deprecated:** January 31, 2023 **End of life:** July 31, 2023 Auth0 will no longer support the auth0-claims-provider add-on for Sharepoint 2010/2013 after July 31, 2023. Without this add-on, you won’t be able to use the “Sharepoint People Picker” with Auth0 connections to assign permissions to Sharepoint 2010/2013 users. You must remove any integrations with the auth0-claims-provider add-on before July 31, 2023. After that date, any remaining integrations with the auth0-claims-provider add-on will cease to function properly and may impact users of your applications. ## Checkpoint Pagination on Get Role Users Endpoint **Deprecated:** November 9, 2022 **End of life:** May 9, 2023 To improve performance, the Get Role Users Management API endpoint will only return greater than 1,000 total results if the checkpoint pagination method is used. This pagination method is optimized to support large quantities of results. The offset pagination method will be capped at 1,000 results. For implementation details for the two pagination methods, read the [Management API documentation for the Get Role Users endpoint](https://auth0.com/docs/api/management/v2/roles/get-role-user). ## Legacy Custom Claims **Deprecated:** July 28, 2022 (Public Cloud), August 31, 2022 (Private Cloud) **End of life:** January 30, 2023 (Public Cloud), April 18, 2023 (Private Cloud) Beginning January 30, 2023 in Public Cloud and April 18, 2023 in Private Cloud, Auth0 will allow the addition of non-namespaced custom claims to JWT tokens using Auth0 Actions and in responses from the Authentication API `/userinfo` endpoint. Previously, Auth0 allowed namespaced claims on access and ID tokens via extensibility code ([Rules](/docs/customize/rules) / [Hooks](/docs/customize/hooks) / [Actions](/docs/customize/actions)). The migration to custom claims allows private, non-namespaced custom claims and OIDC user profile claims to be added to access tokens; ID tokens currently support user profile claims and will additionally support private, non-namespaced custom claims. These claims will also be added to the Auth0 `/userinfo` response. To begin the migration, read the [Custom Claims Migration Guide](/docs/troubleshoot/product-lifecycle/past-migrations/custom-claims-migration). If your tenant is running extensibility code ([Rules](/docs/customize/rules) / [Hooks](/docs/customize/hooks) / [Actions](/docs/customize/actions)) that tries to set non-namespaced custom claims that are being ignored until this deprecation, then those claims will begin to appear on the tokens and the `/userinfo` response. We recommend you review your configuration and Auth0 logs. With the addition of non-namespaced, private claims, Auth0 is enforcing the following restrictions that could potentially affect your tenant: * Auth0 will restrict the custom claims payload to a maximum of 100KB. * Auth0 will restrict the customization/modification of OPENID standard claims or claims used internally by Auth0. * In the future, Auth0 may restrict the use of other claims not included in the above list. In those cases, customers will be notified with a reasonable time to migrate. * Auth0 will restrict the creation of private, non-namespaced custom claims on access tokens with an Auth0 audience, excluding the `/userinfo` endpoint. * Only specified OIDC user profile claims can be added to access tokens. * Auth0 will restrict creating a custom claim starting with a \$ character. To learn more about custom claims, review [Create Custom Claims](/docs/secure/tokens/json-web-tokens/create-custom-claims). ## Legacy Private Cloud Platform **Deprecated:** June 13, 2022 **End of life:** January 31, 2023 We’re making improvements to the underlying infrastructure that supports Auth0 Private Cloud by introducing a modern Kubernetes-based technology stack, as well as database upgrades. We are currently working with all Auth0 Private Cloud customers to schedule the upgrade of their private cloud deployment to the new infrastructure stack during the course of this year, and will be discontinuing the older stack by January 31, 2023. In addition, 2205 (May 2022 release) is the last official release for the legacy Private Cloud platform. Any bugs or security vulnerabilities will be assessed and addressed in patch releases as necessary.  Prior to upgrading to the new infrastructure stack, environments will need to be updated to the minimum compatible version to support the upgrade efforts. Please reach out to your Technical Account Manager with any questions. ## Log Extensions **Deprecated:** May 4, 2022 (Public Cloud), June 9, 2022 (Private Cloud release 2205) **End of life:** May 2, 2023 (Public Cloud), January 6, 2023 (Private Cloud) Beginning May 4, 2022, in Public Cloud and June 9th, 2022, in Private Cloud, the following Auth0 Log Extensions will be deprecated: * 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 **Deprecated:** November 2, 2022 (Public Cloud), December 21, 2022 (Private Cloud) **End of life:** May 2, 2023 (Public Cloud), May 31, 2023 (Private Cloud) Beginning November 2, 2022 in Public Cloud and December 21, 2022 in Private Cloud, the following Auth0 Log Extensions will be deprecated: * Logs to Segment * Logs to Mixpanel * Logs to AppInsights * Logs to Azure Blob Storage All the Log extensions listed above are now deprecated. You can set up equivalent functionality using log event streams or integrations on the [Auth0 Marketplace](https://marketplace.auth0.com/). On November 2, 2022 in Public Cloud and December 21, 2022 in Private Cloud, Auth0 will no longer support the installed log extensions from the list above. For more information, read [Migrate from Log Extensions](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-from-log-extensions). ## Tenant Hostname Validation **Deprecated**: December 9, 2021 and December, 2021 (Private Cloud Release 2112.2) **End of life**: June 9, 2022 and September 9, 2022 (Private Cloud) As of June 9, 2022 in Public Cloud and September 9, 2022 in Private Cloud, Auth0 will increase the security of API calls by adding a validation step for tenant hostnames to the Authentication API’s identification process. When a call is made, the Authentication API will validate the entity identifier (eg: `client_id`) of the requesting tenant as well as the tenant name in the URL domain. The tenant owning the identifier **must** be from the same tenant in the URL domain or the request will be rejected. If your application or API calls any of the listed endpoints, you must configure your API calls to make sure the identifier of the requesting tenant and hostname are the same: * `/oauth/token` * `/co/authenticate` * `/userinfo` * `/login` * `/oauth/revoke` * `/mfa/challenge` * `/p//` (Enterprise connection provisioning endpoint) To learn more, read [Tenant Hostname Validation Migration](/docs/troubleshoot/product-lifecycle/past-migrations/tenant-hostname-migration). ## Node.js 16 Migration **End of life**: April 30, 2022 On 30 Apr 2022, [Node.js v12 went out of long-term support (LTS)](https://github.com/nodejs/Release#release-schedule), which means that the Node.js development team no longer back-ports critical security fixes to this version. This could potentially expose your extensibility code to security vulnerabilities. Therefore, Auth0 is migrating from Node 12 to Node 16. Although the Node 16 update will not introduce any breaking changes in the Node.js standard library (Rules and Custom Database Action Scripts are affected; see the [Breaking changes - Rules and Custom Database Action Scripts only](#breaking-changes-rules-only) section), we encourage customers on Node version 12 to stay current with Active Long-Term Support (LTS) Node versions for security and compliance purposes. Customers who are still on Node 8 are out of security compliance and must migrate to Node 16 to eliminate security risks. We removed the Node 8 runtime on 22 Feb 2022 for Public Cloud tenants and removed it in the April 2022 Private Cloud release. After these dates, tenants still set to Node 8 run the risk of a service interruption. ## Opaque Access Token and Authorization Code Fixed Length **Deprecated**: October 7, 2021 (Public Cloud), December 2021 (Private Cloud) **End of life**: April 12, 2022 (Public Cloud), June 30, 2022 (Private Cloud) Beginning April 12, 2022 in Public Cloud and with the December 2021 Private Cloud, access token and authorization codes will be issued with varied lengths to support [OAuth specification RFC6749](https://datatracker.ietf.org/doc/html/rfc6749) to avoid clients making assumptions about authorization code and access token values. Currently, the access token and authorization code sizes are fixed. The current size of the authorization code is shorter than what some security practitioners recommend. Through this change, Auth0 provides a stronger code and token while also improving the performance of Auth0 systems. Customers with systems configured to rely on specific-sized authorization code and access token length must change from fixed-sized to variable-sized configurations before April 12, 2022 in Public Cloud or the June 30, 2022 Private Cloud release. ## Node.js v8 Extensibility Runtime End of Life **Deprecated**: 15 April 2020 **End of life**: 25 February 2022 (Public Cloud), April 2022 (Private Cloud release) Beginning 13 December 2019, [Node.js v8 was no longer under long-term support (LTS)](https://github.com/nodejs/Release#release-schedule). This means that critical security fixes were no longer back-ported to this version. Customers who are still on Node 8 are out of security compliance and must migrate to Node 12 to eliminate security risks. To learn more about how to migrate your tenant-level Node version from 8 to 12, read [Migrate from Node.js 8 to Node.js 12](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-nodejs-12). Because Node.js v12 is also going out of LTS in 2022, we also highly encourage all customers using Rules and Hooks to migrate to Actions using Node 16 as soon as possible, and before Node 12 support expires formally from the Node.js community on 30 April 2022. To learn more about required migration steps, read [Migrate Rules and Hooks to Actions](/docs/customize/actions/migrate/migrate-from-rules-to-actions). ## Legacy Network Edge Deprecation **Deprecated**: 05 May 2021 (Public Cloud) **End of life**: 03 November 2021 (Public Cloud) Auth0 legacy network edge will cease to function on Public Cloud. After 03 November 2021, Public Cloud tenants who have not completed a migration to the new Auth0 network edge will no longer receive traffic. All new custom domains are automatically created on the new network edge. ## Unpaginated Management API v2 Request deprecation **Deprecated**: 21 July 2020 (Public Cloud) **End of life**: 26 January 2021 (Public Cloud), February 2022 (Private Cloud release) After 26 January 2021, requests to the following Management API v2 endpoints will return a maximum of 50 items for Public Cloud tenants. To retrieve more items, you must include `page` and `per_page` parameters. Beginning on 21 July 2020, Auth0 will display tenant logs and a migration toggle to help you prepare for this change. * [`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)(when the `type` query parameter is used) * [`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) All Public Cloud tenants are affected that are created before 21 July 2020 and are actively calling affected endpoints without passing the `per_page` parameter for queries that can return more than 1 result. Tenants are not affected if they are created after 21 July 2020, are not using the affected endpoints, are using the affected endpoints and passing the `per_page` parameter, or are making queries that always return only 1 result. To learn more, read [Migrate to Management API v2 Endpoint Paginated Queries](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-paginated-queries). ## Private Cloud Custom Domain Deprecation **Deprecated**: 17 June 2021 **End of life**: 20 December 2021 To achieve consistency across all Auth0 deployments and focus on enhancing the Auth0 Custom Domain feature, we are discontinuing the Private Cloud Custom Domain capability on December 20, 2021. Consistency enables us to enhance the feature and fix reliability issues faster, improving operational efficiency and enabling customers to get value out of custom domains more quickly. ## Logout Redirect Validation **Deprecated**: 25 May 2021 **End of life**: 01 December 2021 On 01 December 2021, the logout behavior will change to always redirect users to the URI passed to the Auth0 logout APIs instead of using the `returnTo` query parameter passed by Identity Providers to `/login/callback` during the execution of the logout. If Auth0 does not have a record of a preceding call to one of these APIs, logout will complete, but redirection will not occur and an error page will be displayed to end users. To learn more, read [Logout Redirects Migration Guide](/docs/troubleshoot/product-lifecycle/deprecations-and-migrations/logout-return-to). ## Application Admin Dashboard Role deprecation **Deprecated**: 01 February 2021 **End of life**: 30 September 2021 (Public Cloud), September 2021 (Private Cloud monthly release) Auth0 is changing the role-based access control to the Dashboard. The Application Administrator role as defined today is being deprecated. After 01 February 2021, administrators won't be able to invite members with the deprecated Application Administrator role. Existing application-specific administrators will continue to be able to use the Dashboard with the existing permission set until the end of life date. A new set of Dashboard roles is available for improved and more secure collaboration among team members, including viewer and editor roles with limited access. A new **Editor - Specific Apps** role replaces the previous **Application Administrator** role for subscription plans where editor roles are supported. Your tenants will be affected by this deprecation if the following criteria are met: * Created before 01 February 2021 * Have at least one tenant member with the **Application Admin** role * Haven't opted-in to the Dashboard roles feature preview Beginning on 01 February 2021, Auth0 will display a migration toggle to help you prepare for this change. To learn more, read [Migrate to Manage Dashboard New Roles](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-tenant-member-roles). ## Legacy TLS Deprecation **Deprecated**: 19 January 2021 **End of life**: 10 May 2021 (Public Cloud), June Private Cloud Release (v2106) As of 10 May 2021 for Public Cloud and the June Private Cloud Release (v2106), the Auth0 network edge will no longer accept TLS 1.0 or TLS 1.1 traffic.  These legacy protocols are insecure, with well-known weaknesses and vulnerabilities within the industry.  For maximum security, all Auth0 clients must upgrade to TLS 1.2 or later. The exact details and steps required will vary, depending on your application. ## Auth0-analytics.js deprecation **Deprecation**: January 2018 **End of life**: January 2021 Auth0 has deprecated the use of the [auth0-analytics.js library](https://github.com/auth0/auth0-analytics.js/) that adds Facebook and Google Analytics integration with Lock. It listens for events in Lock and passes them to the Auth0-tag-manager.js library. It may still function in some legacy cases. This library is no longer maintained. You may need to write custom code to use [auth0-tag-manage.js](https://github.com/auth0/auth0-tag-manager) to manage proxy requests to third-party analytics libraries such as Facebook, X, and Google. ## Device credential metadata without user\_id deprecation **Deprecated**: 31 August 2020 **End of life**: 17 December 2020 Auth0 now requires that you provide the `user_id` when you use the [GET /api/v2/device-credentials endpoint](https://auth0.com/docs/api/management/v2/#!/Device_Credentials/get_device_credentials). If your request does not provide a `user_id`, it will return a 400 status code. Check the `depnote` in your tenant logs to see if you are affected by this deprecation. Auth0 has identified tenants affected by this deprecation and contacted the administrators for those tenants. If your tenant is currently making requests without a `user_id`, you should make the change as soon as possible. ## Azure AD/ADFS email verification deprecation **Deprecated**: * Public Cloud: 18 November 2020 * Private Cloud: 01 December 2020 **End of life**: * Public Cloud: 18 May 2021 * Private Cloud: June Private Cloud Release (v2106) Auth0 previously set the `email_verified` field to true in Azure AD and ADFS connections. If you used Azure AD/ADFS connections before this deprecation date, you have a tenant setting that overrides the connection setting for email verification and keeps the previous behavior. On 18 May 2021 in Public Cloud and the June Private Cloud Release (v2106), Auth0 begins using the connection-level property for all Azure AD/ADFS connections. You should make sure all your connections are configured properly before that date. To learn more, read [Email Verification for Azure AD and ADFS](/docs/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification). ## sameSite cookie attribute changes **Effective**: February 2020 Google Chrome v80 is changing the way it handles cookies. To that end, Auth0 will implement the following changes in the way it handles cookies: * Cookies without the `samesite` attribute set will be set to `lax` * Cookies with `sameSite=none` must be secured, otherwise they cannot be saved in the browser's cookie jar The goal of these changes is to improve security and help mitigate CSRF attacks. For details, see [sameSite Cookie Attribute Changes](/docs/manage-users/cookies/samesite-cookie-attribute-changes). ## User Search v2 deprecation **Deprecated**: 10 November 2018 **End of life**: 30 June 2019 (Public Cloud), May 2021 (Private Cloud monthly release) For Public Cloud, User Search v2 was deprecated and you should have taken action before 30 June 2019. Notifications were sent to customers that need to complete this migration. For Private Cloud, User Search v1 and v2 endpoints will be no longer be available after the May Private Cloud monthly release and have been replaced with the new User Search v3 endpoint. ## Passwordless Endpoint from Confidential Applications deprecation Auth0 has deprecated the use of the `/passwordless/start` endpoint from confidential applications when Auth0 cannot authenticate that the call is made on behalf of the application. To learn more, read [Migrate to Passwordless Endpoint from Confidential Applications](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-passwordless).Clickjacking Protection for Universal Login changes To prevent clickjacking, in cases where you render your login page in an iframe, Auth0 has added an opt-in to add headers which we strongly recommend you enable. For details, see [Clickjacking Protection for Universal Login Change](/docs/troubleshoot/product-lifecycle/past-migrations/clickjacking-protection-for-universal-login). ## Management API endpoints using ID token credentials deprecation **Deprecation**: 31 March 2018 **End of life**: TBD Auth0 is deprecating the use of ID tokens as credentials to call some of the users and device endpoints and replacing it with the use of access tokens instead. For details, see [Migrate to Management API Endpoints with Access Tokens](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-calling-api-with-access-tokens) and [Migrate to Link User Accounts with Access Tokens](/docs/troubleshoot/product-lifecycle/past-migrations/link-user-accounts-with-access-tokens-migration). ## Resource Owner Password /oauth/ro deprecation **Deprecation**: 08 July 2017 **End of life**: TBD As of 08 July 2017 Auth0 has deprecated the`/oauth/ro` endpoint for both password and passwordless connections. You can now implement the same functionality using the `/oauth/token` endpoint. To learn more, read [Resource Owner Password Flow Migration](/docs/troubleshoot/product-lifecycle/past-migrations/migration-oauthro-oauthtoken). ## Management API v1 deprecation **Deprecation**: October 2016 **End of life**: * Public Cloud: 13 July 2020 * Private Cloud: November 2020 monthly release Management API v1 will reach its End of Life in the Public Cloud on 13 July 2020. Management API v1 will be included in the Private Cloud until the November 2020 monthly release, which is the first release that will not include Management API v1. You may be required to take action before that date to ensure no interruption to your service. Notifications have been and will continue to be sent to customers that need to complete this migration. ## Instagram connection deprecation **Deprecated**: 05 March 2020 **End of life**: 31 March 2020 Facebook announced that on 31 March 2020 that they will turn off the Instagram legacy APIs, and they won't provide an alternative to implement login with Instagram. For details, see [Instagram Connection Deprecation](/docs/troubleshoot/product-lifecycle/past-migrations/instagram-connection-deprecation). ## Yahoo API changes **Deprecated**: 01 March 2020 **End of life**: 01 March 2020 Yahoo changed the way to retrieve the user profile and the information included in it. For details, see [Yahoo API Changes](/docs/troubleshoot/product-lifecycle/past-migrations/yahoo-api-changes). ## Google Cloud Messaging deprecation **Deprecation**: 11 April 2019 **End of life**: 11 April 2019 As of 11 April 2019, [Google deprecated](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) and replaced Google Cloud Messaging (GCM) with Firebase Cloud Messaging (FCM). For details, see [Google to Firebase Cloud Messaging Migration](/docs/troubleshoot/product-lifecycle/past-migrations/google-firebase-migration). ## Facebook Social Context field deprecation **Deprecation**: 30 April 2019 **End of life**: 30 July 2019 On 30 April 2019, Facebook deprecated the use of the **Social Context** field for new applications. For details, see [Facebook Social Context Field Deprecation](/docs/troubleshoot/product-lifecycle/past-migrations/facebook-social-context-field-deprecation). ## Facebook Graph API changes **Deprecation**: 01 August 2018 **End of life**: Graph API v3 released 08 January 2019 As of 01 August 2018, Facebook has changed the Facebook Graph API permissions and fields that can be requested. Auth0 has updated Facebook Connections to reflect these changes and modified the connection interface for clarity. See [Facebook Login Changelog: Recent Changes to Facebook Login](https://developers.facebook.com/docs/facebook-login/changelog#2018-07-02) for complete details and key dates. For details, see [Facebook Graph API Changes](/docs/troubleshoot/product-lifecycle/past-migrations/facebook-graph-api-changes). ## Lock v11 and Auth0.js v9 We are continually improving the security of our service. As part of this effort, we have deprecated the Legacy Lock API, which consists of the `/usernamepassword/login` and `/ssodata` endpoints. These endpoints are used by Lock.js v8, v9, and v10 and Auth0.js, v6, v7, and v8, and can also be called directly from applications. As of August 6, 2018, Auth0 has permanently disabled the Legacy Lock API. This removal of service fully mitigates the CSRF vulnerability [disclosed in April 2018](https://auth0.com/blog/managing-and-mitigating-security-vulnerabilities-at-auth0/). This also ends the soft removal grace period that was first announced on 16 July 2018, meaning the Legacy Lock API can no longer be re-enabled. If your Legacy Lock API migration has not yet been completed, your users may experience an outage, failed logins, or other adverse effects. You will need to complete your migration in order to restore normal functionality. Check deprecation errors to identify the source(s) of any errors in your tenant logs related to deprecations. ### Features affected If you are currently implementing login in your application with Lock v8, v9, or v10, or Auth0.js v6, v7, or v8, you are affected by these changes. Additionally, you are affected if your application calls the `/usernamepassword/login` or `/ssodata` endpoints directly via the API. We recommend that applications using Universal Login update the library versions they use inside of the login page. However, those who are using Lock or Auth0.js embedded within their applications, or are calling the affected API endpoints directly, are required to update, and applications which still use deprecated endpoints will cease to function properly after the removal of service date. Libraries and SDKs not explicitly named here are not affected by this migration. ## Tenant Log Search v2 deprecation **Deprecation**: 21 May 2019 **End of life**: * Free: 09 July 2019 * Essential (former Developer): 20 August 2019 * Professional (former Developer Pro): 20 August 2019 * Enterprise: 04 November 2019 To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3. Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt in for v3 during the provided grace period. For details, see [Migrate to Tenant Log Search v1 to V2](/docs/troubleshoot/product-lifecycle/past-migrations/migrate-to-tenant-log-search-v3). ## New IP addresses for Allowlisting in Australia As of 30 September 2017, Auth0 updated its cloud environments and traffic from Australia originates from new IP addresses. If you are allowlisting IP addresses, you will need to add the new addresses to your firewall rules. ### Features affected If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, **and** you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to make sure the following IP addresses are allowed to go through your firewall: `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` ## New IP addresses for allowlisting in Europe As of 30 September 2017, Auth0 updated its cloud environments and traffic from Europe originates from new IP addresses. If you are allowlisting IP addresses, you will need to add the new addresses to your firewall rules. ### Features affected If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, and you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to make sure the following IP addresses are allowed to go through your firewall: `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 provider migration in the Europe and Australia environments As of 12 July 2017, Auth0 has improved the Auth0 CDN scaling and availability. We now use Amazon CloudFront. We have already made this change in the US environment, and are now ready to do so in Europe and Australia. ### Features affected You are affected if you use Lock (hosted by our CDN) in Europe or Australia. This change shouldn't cause any disruption or change in behavior in your applications, so you don't have to do anything. This notification is for information only. ## Password and refresh token exchange rules migration On 31 May 2017, as part of Auth0's efforts to improve security, we added the ability to execute rules during the OAuth 2.0 Resource Owner Password Grant exchange (the password exchange) and the refresh token exchange. ### Features affected You are using this feature if you are calling the `/oauth/token` endpoint of our Authentication API with `grant_type = "password"` , `grant_type = "http://auth0.com/oauth/grant-type/password-realm"`, or `grant_type = "refresh_token"`. You could be impacted if you are currently using these exchanges and have rules defined in Dashboard. In order to ensure a smooth transition, we have disabled the rules execution on these specific exchanges for your tenant. These rules will now execute for all new customers, as well as customers who have not yet used these exchanges. You can add logic to your rules to alter their behavior for these exchanges by checking the `context.protocol` property: * `oauth2-password` indicates the password (and password-realm) exchange * `oauth2-refresh-token` indicates the Refresh Token exchange If you would like to enable the new behavior on this tenant for testing before the mandatory opt-in date, login to [Dashboard](https://manage.auth0.com/#) and enable the **Run Rules on Password and Refresh Token Exchanges** toggle in [Tenant Settings > Advanced](https://manage.auth0.com/#/tenant/advanced). ## Account linking removal On 01 March 2017, as part of Auth0's efforts to improve security and standards compliance, we stopped supporting account linking as part of the authorization callback (that is, accepting an access token as part of the authorize call). ### Features affected If you received an email notification about it, then you are impacted by this change. As you work to update your applications to use the Management API to link accounts, you can check if you are still impacted, by checking your tenant logs for warnings. These entries will be logged if you are sending an Access Token in your authorize calls. ## Allowlist IP address ranges As of 20 February 2017, Auth0 expanded into new US regions and traffic originating from these regions will have new IP addresses. If you allowlist IP addresses you will need to add the new addresses to your firewall rules. ### Features affected If you are using a custom database connection, rule, and/or custom email provider that connects to your environment, and you have implemented firewall restrictions for IP address ranges, then you are affected by this change. You will need to add the following IP addresses to your firewall rules: `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` ## Vulnerable password flow Prior to 01 February 2017, Auth0's password reset flow allowed a user to enter their email and a new password. This triggered a confirmation email that to be sent to the user asking them to confirm that they requested a password reset. ### Features affected The issue is that the confirmation link could be inadvertently clicked by a user which would result in the user's password being changed by an attacker. Lock version 9 and above uses the new password reset flow exclusively. Lock 8 and below does not handle the new password reset flow. We strongly recommend upgrading to Lock 9 or greater as soon as possible. Even if you are not using Lock, the vulnerable reset flow can be accessed directly through the API. (See the /dbconnections/change\_password endpoint for details.) Auth0 strongly encourages you to change any app using the current flow to move immediately to the new reset flow and enable this migration. ## State parameter required on redirect from rule As of 06 December 2016, when a redirect is done from an Auth0 rule, Auth0 generates and sends a state parameter in HTTP and check for a valid state parameter when flow returns to the `/continue` endpoint. The site to which the redirect goes has to capture the value of the state parameter and return it by adding it as a parameter when returning to the `/continue` endpoint. ### Features affected You are affected by the change only if you redirect from rules, and do not yet capture and return (to the /continue end point) the state parameter. ## Delete all users endpoint change Prior to 13 September 2016, the previous endpoint for deleting all users was `DELETE /api/v2/users`. This is similar to the endpoint to delete one user: DELETE `/api/v2/users`. To prevent accidental requests to the delete all users endpoint, the url has been changed to `DELETE /api/v2/allusers`. This should ensure that only intentional calls to this endpoint get made. ### Features affected You are affected by the change only if you currently make use of the delete all users endpoint. If so, the only change you need to make is to change the URL as explained above. ## Email delivery template customization changes As of 29 August 2016, Auth0's built-in email provider is longer be supported for use in a production environment. The emails sent using the Auth0 provider will no longer be customizable. They will be restricted to the template and you will not be able to change the from address or subject line. The built-in email service may still be used for test purposes but you must switch to an Auth0-supported third-party service ([Amazon SES](https://aws.amazon.com/ses/), [Mailchimp](https://mailchimp.com/features/transactional-email/), [SendGrid](https://sendgrid.com/en-us/pricing) or another SMTP-based provider before moving your apps to production. If you already use a custom email provider, no action is necessary. ## Identity provider access tokens removed from user profile and ID token As of 08 August 2016, the format of the user profile JSON object (ID token) that is returned by Auth0 Authentication APIs changed to remove the identity provider access token and included in the user profile `identities` array. To obtain a user's identity provider access token, you will need to make an HTTP GET call to the `/api/v2/users/{user-id}` endpoint containing an API token generated with `read:user_idp_tokens` scope. You will still have access to the identity provider access token in the `user` argument in Auth0 rules. ### Features affected You are affected by the change only if you are using the Identity Provider Access Token (`identities[0].access_token` in the user profile) outside of rules to call other services from the Identity Provider (such as Facebook Graph API, Google APIs, etc.). If your tenant was created after the change the update will be done automatically. ## Tokeninfo endpoint validation As of 01 June 2016, when calling the Tokeninfo endpoint, the URL of the API call (for example `https://{yourDomain}/`) must match the value of the `iss` attribute of the ID Token being validated. If these values do not match, the response will be `HTTP 400 - Bad Request`. ### Features affected If you are calling the Tokeninfo endpoint directly, make sure that the value of the `iss` attribute of the ID Token being validated matches your Auth0 tenant namespace: `https://{yourDomain}/`. You can use [jwt.io](https://www.jwt.io/) to decode the token to confirm the `iss` attribute value. ## Email delivery from address changes On 27 April 2016, Auth0's built-in email provider started sending all emails from a predefined from address (`no-reply@auth0user.net`). Custom Email Providers are now free. To customize the "from" address, you can switch to an Auth0-supported third-party service ([Amazon SES](https://aws.amazon.com/ses/), [Mailchimp](https://mailchimp.com/features/transactional-email/), [SendGrid](https://sendgrid.com/en-us/pricing)) or another SMTP-based provider. If you already use a custom email provider, nothing will change. ## Patch and Post endpoints no longer accept secret\_encoded flag The `jwt_configuration.secret_encoded` configuration is no longer accepted by the PATCH and POST applications endpoints. In order to further comply with the OIDC specification, Auth0 will no longer generate or accept base64 encoded application secrets for new applications. Existing applications with encoded secrets stored will remain intact and unchanged, but new applications will no longer use base64 encoding. The `secret_encoded` flag is no longer accepted or necessary, as a result. ### Features affected You are affected by this change only if you interact with these endpoints directly.