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: June 5, 2024

End of life: August 5, 2024

Access to view Subscription 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.

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.

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.

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. This evaluation will validate that all scopes are registered, returning an error if any are not registered.

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 | migration guide

• angular-auth0 | migration guide

• auth0-cordova | migration guide

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.

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.

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.

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.

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.

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.

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.

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

If your tenant is running extensibility code (Rules / Hooks / 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.

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.

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

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/<connection-type>/<ticket> (Enterprise connection provisioning endpoint)

To learn more, read Tenant Hostname Validation Migration.

End of life: April 30, 2022

On 30 Apr 2022, Node.js v12 went out of long-term support (LTS), 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 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.

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

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/connections

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