Auth0 Migrations

Occasionally, Auth0 engineers must make breaking changes to the Auth0 platform, primarily for security reasons. If a vulnerability or other problem in the platform is not up to our high standards of security, we work to correct the issue.

Sometimes a correction will cause a breaking change to customer's applications. Depending on the severity of the issue, we may have to make the change immediately.

For changes that do not require immediate changes, we often allow a grace period to allow you time to update your applications.

Migration process

The migration process is outlined below:

  1. We update the platform and add a new migration option for existing customers, allowing a grace period for opt-in. New customers are always automatically enrolled in all migrations.
  2. After a certain period, the migration is enabled for all customers. This grace period varies based on the severity and impact of the breaking change, typically 30 or 90 days.

During the grace period, customers are informed via dashboard notifications and emails to tenant administrators. You will continue to receive emails until the migration has been enabled on each tenant you administer.

If you need help with the migration, create a ticket in our Support Center.

Active migrations

Current migrations are listed below, newest first.

For migrations that have already been enabled for all customers, see Past Migrations.

Tenant Logs Search v2 migration to v3

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. A migration guide is available with more details on affected customers and steps required to complete the migration.

IP Address Authentication Deprecation

IP Address Authentication has been deprecated and will not be enabled for new customers. The functionality will continue to work for existing customers that currently have it enabled. If at some point the IP Address Authentication feature is changed or removed from service, customers who currently use it will be notified beforehand and given ample time to migrate.

User Search v2 migration to v3

User Search v2 is being deprecated and you may be required to take action before June 30, 2019. A migration guide is available to walk you through the steps required. Notifications have been and will continue to be sent to customers that need to complete this migration.

Useful Resources:

Google Cloud Messaging to Firebase Cloud Messaging Migration

Auth0’s Guardian SDKs for iOS and Android helps you create custom Mobile apps with Guardian functionality, providing secure access to multi-factor authentication with push notifications.

The Android SDK library was initially built to send Push Notifications using Google Cloud Messaging, which Google deprecated and replaced with Firebase Cloud Messaging. We updated the SDK to use Firebase Cloud Messaging.

Existing applications will keep working but if you want to migrate, you can find instructions here.

Facebook Login and Graph API

The latest version of Facebook Login and the Facebook Graph API change what permissions and fields can be requested. We've updated Facebook connections to reflect these changes. For for more information, check out Changes to Facebook Login and Graph API.

LinkedIn API V2

On March 1st, 2019 all LinkedIn connections will be updated to use version 2 of the LinkedIn API. You may need to update your application code to accomodate these API changes. For more information, check out Migration to LinkedIn API V2.

Node.js v8 for Webtask Runtime

Severity Grace Period Start Mandatory Opt-In
High 2018-04-17 2018-04-30

The Webtask engine powering Auth0 extensibility points currently utilizes Node 4. Beginning 30 April 2018, Node.js v4 will no longer be under long-term support (LTS). This means that critical security fixes will no longer be back-ported to this version. As such, Auth0 will be migrating the Webtask runtime from Node.js v4 to Node.js v8.

On 17 April 2018 we will make the Node 8 runtime available for extensibility to all public cloud customers. You will be provided a migration switch that allows you to control your environment's migration to the new runtime environment.

For more information on this migration and the steps you should follow to upgrade your implementation, see Migration Guide: Extensibility and Node.js v8.

Introducing Lock v11 and Auth0.js v9

Severity Grace Period Start Mandatory Opt-In
Medium 2017-12-21 2018-08-06

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 July 16, 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. Refer to the Legacy Lock API Deprecation Guide to determine the correct path for your needs; you may also wish to consult the Deprecation Error Reference to identify the source(s) of any errors in your tenant logs.

Am I affected by the change?

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.

If you have any questions, reach out in our Support Center.

Deprecating the usage of ID Tokens on the Auth0 Management API

Severity Grace Period Start Mandatory Opt-In
Medium 2018-03-31 -

For some use cases you can use ID Tokens as credentials in order to call the Management API. This functionality is being deprecated.

This is used by the Users and Device Credentials endpoints.

List of affected endpoints:

Endpoint Use Case
GET /api/v2/users/{id} Retrieve a user's information
GET /api/v2/users/{id}/enrollments Retrieve all Guardian MFA enrollments for a user
PATCH /api/v2/users/{id} Update a user's information
DELETE /api/v2/users/{id}/multifactor/{provider} Delete the multifactor provider settings for a user
POST /api/v2/device-credentials Create a public key for a device
DELETE /api/v2/device-credentials/{id} Delete a device credential
POST/api/v2/users/{id}/identities Link user accounts from various identity providers
DELETE /api/v2/users/{id}/identities/{provider}/{user_id} Unlink user accounts

These endpoints can now accept regular Access Tokens.

The functionality is available and affected users are encouraged to migrate. However the ability to use ID Tokens will not be disabled in the foreseeable future so the mandatory opt-in date for this migration remains open. When this changes, customers will be notified beforehand.

For more information on this migration and the steps you should follow to upgrade your implementation, see the Migration Guide: Management API and ID Tokens.

Am I affected by the change?

If you are currently using ID Tokens to access any part of the Management API, your application will need to be updated.

If you have any questions, create a ticket in our Support Center.

Upcoming migrations

Based on customer feedback, we have adjusted our plans and will continue to maintain and support the below listed endpoints and features.

We will publish guidance for each of the below scenarios on how to transition your applications to standards-based protocols. If we need to make security enhancements to any of these legacy endpoints which would require more urgency, we will promptly announce timeframes and guidelines for any required changes.

Resource Owner support for /oauth/token endpoint

Support was introduced for Resource Owner Password to the /oauth/token endpoint earlier this year.

Am I affected by the change?

If you are currently implementing the /oauth/ro endpoint your application can be updated to use the /oauth/token endpoint. For details on how to make this transition, see the Migration Guide for Resource Owner Password Credentials Exchange.

If you have any questions, create a ticket in our Support Center.

API authorization with third-party vendor APIs

The mechanism by which you get tokens for third-party / vendor APIs (for example AWS, Firebase, and others) is being changed. It will work the same as any custom API, providing better consistency. This new architecture will be available in 2019 and once it becomes available, the /delegation endpoint will be officially deprecated.

Am I affected by the change?

If you are currently using /delegation to provide third party authorization, your application will need to be updated once migration guides are available.

If you have any questions, create a ticket in our Support Center.

Improved OpenID Connect interoperability in Auth0

The userinfo endpoint is being updated to return OIDC conformant user profile attributes. The most notable change is that user_id becomes sub. This will deprecate the legacy Auth0 user profile (in userinfo and in ID Tokens).

Am I affected by the change?

If you are currently using the /userinfo endpoint or receiving ID Tokens, you are affected by this change and need to update your implementation so that it expects normalized OIDC conformant user profile attributes once migration guides are available.

If you have any questions, create a ticket in our Support Center.