Past Migrations

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.

Legacy TLS Deprecation

Deprecated: 19 January 2021

End of life:

  • Public Cloud: 10 May 2021

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

Auth0-analytics.js deprecation

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.

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

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.

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.

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

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

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.

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.

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.

Google Cloud Messaging deprecation

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.

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.

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

  • Developer: 20 August 2019

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

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

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

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://YOUR_DOMAIN/) 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://YOUR_DOMAIN/. You can use 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, Mandrill, SendGrid) 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.