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.

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

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.

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.

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

• GET /api/v2/client-grants

• GET /api/v2/grants

• GET /api/v2/connects

• GET /api/v2/device-crecentials (when the type query parameter is used)

• GET /api/v2/resource-servers

• GET /api/v2/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.

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. To learn more about migration to Auth0 Custom Domains, read Migrate Private Cloud Custom Domains.

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.

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.

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. To learn more, read Upgrade to TLS 1.2, what action to take? posted in the Auth0 Community.

Deprecation: January 2018

End of life: January 2021

Auth0 has deprecated the use of the auth0-analytics.js library 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 to manage proxy requests to third-party analytics libraries such as Facebook, Twitter, and Google.

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. 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. To learn more, read Check Deprecation Errors.

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.

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.

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.

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.

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

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 and Migrate to Link User Accounts with Access Tokens.

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.

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.

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.

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.

Deprecation: 11 April 2019

End of life: 11 April 2019

As of 11 April 2019, Google deprecated and replaced Google Cloud Messaging (GCM) with Firebase Cloud Messaging (FCM). For details, see Google to Firebase Cloud Messaging Migration.

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.

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 for complete details and key dates. For details, see Facebook Graph API Changes.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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 and enable the Run Rules on Password and Refresh Token Exchanges toggle in Tenant Settings > Advanced.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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, Mandrill, SendGrid) or another SMTP-based provider before moving your apps to production. If you already use a custom email provider, no action is necessary.

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.

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.

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.

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 to decode the token to confirm the iss attribute value.

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, Mandrill, SendGrid) or another SMTP-based provider. If you already use a custom email provider, nothing will change.

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.

You are affected by this change only if you interact with these endpoints directly.