john-brennan

John is an R&D Content Engineer at Auth0. He has nearly a decade’s experience in full-stack software development in a variety of environments, languages, and frameworks. He relishes the challenge of learning hard-to-grasp technical concepts and helping others understand them in a clear, concise manner. His current technical interests are in API design and scalability, Ruby on Rails, accessibility, single-page app architecture, and the ever-changing JavaScript ecosystem. When he's not working, John is usually cooking, doing creative writing, running, or wrangling a toddler.

R&D Content Engineer

John Brennan

Learn techniques for migrating your users from other identity solutions to Auth0



**TL;DR:** This tutorial will walk you through options for migrating users into Auth0, focusing specifically on the challenges you may face when migrating from on-premises identity solutions.

---

## The Basics of Migrating to Cloud Solutions

There may be many reasons that you're migrating away from your on-premises solution. To name just a few:

* The provider might be sunsetting or deprecating the solution you use.
* Licensing fees and vendor lock-in might be proving too restrictive.
* Proprietary or non-standard authentication/authorization approaches might be limiting compatibility with new cloud-based products and services.
* The complexity of managing a suite of identity products yourselves might be proving too cumbersome to maintain.

Regardless of the reasons, Auth0 provides several solutions for migrating user data into Auth0. Whether you're trying to migrate all of your users at once &mdash; a common scenario if a license is expiring or a product is being deprecated &mdash; or more gradually, there are options at your disposal to bring your user data into Auth0's database. Migration can even include hashed passwords, so your users won't have to reset their credentials after their data has been moved! Once migrated, you can rely on Auth0's standards-based approach to authentication and authorization and easy integration with any number of other identity providers. And, if you ever need to extract user data, [Auth0 provides bulk user export as well](https://auth0.com/docs/users/guides/bulk-user-exports).

<include src="ebook-ads/UserMigrationYourWay" />

## Migration Strategies: Bulk vs. Automatic

Auth0 offers multiple strategies for migrating users from an existing application. Bulk Importing users, either via the Management API or the User Import/Export Extension, provides an easy way to shift your existing user base to Auth0 all at once. Bulk import is a great approach when you rely on a soon-to-be-deprecated identity service or application. If time is a critical factor, bulk import allows you to remove your use of the old application as quickly as possible. That said, this migration process can be time-consuming if you have a large set of user data, and it might require downtime for your application while you switch your users over.

> Thanks to a recent release, hashed user passwords can now be migrated through bulk import if they use a [supporting hash algorithm](https://auth0.com/docs/users/references/bulk-import-database-schema-examples#supported-hash-algorithms). Password migration was previously only possible when running an Automatic Migration.

The other option for user import is Automatic Migration via custom database connections. This option only migrates users when they sign in through Auth0, removing the need for a costly all-in-one database migration. On the other hand, this approach takes longer than bulk migration owing to its one-at-a-time approach, so if your identity service is being deprecated, this approach may present some difficulties.

Each of these approaches is explained in more detail below.

## Considerations When Migrating from On-Premises Solutions

The list of on-premises identity providers is by no means small, and going through how to extract your user data from each one would make the length of this article somewhat untenable! Regardless, if you're migrating from an on-premises identity provider to Auth0, there are some caveats to watch out for during the user export process. The exact state and availability of your user data will depend on the specifics of your provider &mdash; Oracle's on-premises offerings, for example, can differ significantly from IBM's in approach, architecture, and storage. However, there are a few general items to consider when looking to migrate your data.

First, not all on-premises solutions offer easy export of their user databases. Some may not offer export options at all; in cases like this, [Automatic Migration](https://auth0.com/docs/users/guides/configure-automatic-migration) of your user data could be an option. This method lazily migrates user data from your existing system to Auth0 when users sign in. This approach may require additional custom work &mdash; for example, if your identity solution isn't available to the public internet, you may need to build or configure a reverse proxy to allow external requests to reach your identity server. A custom solution like this is non-trivial to implement, but a future blog post will walk through this process in detail.

Secondly, the complexity of an on-premises solution can present a challenge. Some identity solutions are sold as a single product but, under the hood, store their information across multiple databases or servers in their backend. An in-depth understanding of how user data is stored in your current provider is critical to a successful migration.

Lastly, it's necessary to format your data correctly. Auth0 expects user data in a JSON-formatted file following a [well-documented schema](https://auth0.com/docs/users/references/bulk-import-database-schema-examples). Your data almost certainly won't come out of your current system in a ready-to-import format, so depending on what state it's in, it'll probably need to be re-shaped to match the schema expected by Auth0's import processes.

These considerations aren't meant to scare you off, but it's important to know what you're getting into when it comes to migrating user data. Depending on your in-house resources, it may be beneficial to [reach out to us](https://auth0.com/partners), so we can connect you with a technology partner to help with the specifics of your migration.

With all that said, let's get to the import approaches themselves!

## User Migration Strategy #1: Bulk Import

As mentioned, if you use an identity solution that's being deprecated or an on-premises identity solution, bulk migration might be the right approach for you. This section will walk through setting up an Auth0 Database and importing users.

First and foremost, you should start by extracting the data from your existing identity solution and reformatting it to match the [Auth0 user import schema](https://auth0.com/docs/users/references/bulk-import-database-schema-examples), which expects a JSON file containing user information. Ultimately, an `email` is the only required field to import a user, though the more complete your data set is, the better off you are.

As mentioned above, bulk import allows importing users' hashed passwords into Auth0. Previously, bulk importing required all customers to reset their passwords once their user accounts had been migrated due to password information not being viable for migration. However, that's now changed: Auth0 now supports importing hashed passwords by specifying a custom password hash in the import schema. The [Import & Export Users documentation](https://auth0.com/docs/users/references/bulk-import-database-schema-examples#custom-password-hash) contains details on how to format password hashes for import. The bulk importer supports [several standard common hashing algorithms](https://auth0.com/docs/users/references/bulk-import-database-schema-examples#supported-hash-algorithms).

Once you format your users' data to match the schema, you're ready to configure your database in Auth0 for storing those users.

First, you'll need to create a Database Connection that will store your imported users in an Auth0 User Store. Head to your [Auth0 Dashboard](https://manage.auth0.com), then click the "Connections" link in the left-hand menu. Click "Databases" in the submenu, and then click the "Create DB Connection" button in the top right of the page.

![Auth0 Dashboard DB Connections Page](https://images.ctfassets.net/23aumh6u8s0i/6002ObMmLMEGodUm26OIr3/b48f44467e1036ba062bc5bf5aea1364/db-connections-page)

In the "New Database Connection" form, give your new database a name like `on-prem-migrated-users`. If your current identity provider requires usernames instead of email addresses for login, you can enable that feature here. You can also specify if you want to disable sign-ups for this user store.

Once you've filled out the form, click "Create" and your database connection is ready.

![Auth0 DB Connection Creation Form](https://images.ctfassets.net/23aumh6u8s0i/3ploRR9cHO9TJqHVOZ0Jtu/81985f02cf4ff8c95f097fc714fc49cf/create-db-connection-form)

Now that you've created your user store, there are two ways to import your user data: using the [Management API](https://auth0.com/docs/users/guides/bulk-user-imports) or using the [Import Users extension](https://auth0.com/docs/extensions/user-import-export).

### Importing Users via the Management API

The Management API provides an easy way to import your users into Auth0 programmatically. To do so, you'll first need to get a token with which to call the Management API.

Go to your Applications page and click the Create Application button. Select "Machine to Machine application" as the type and give it a name like "User Import."

![Auth0 Machine to Machine Application creation form](https://images.ctfassets.net/23aumh6u8s0i/6CIAkPt2IXah17BgcBDYu1/fc0cdfdb74052975b79a6dd36ba769f3/m2m-application-creation)

In the following form, select "Auth0 Management API" in the dropdown of APIs to authorize for this application. Lastly, select the `create:users` and `read:connections` scope in the select box so that you'll be able to create users with the token you generate. Lastly, click the "Authorize" button to create your application.

![Auth0 Machine to Machine Application creation API scopes](https://images.ctfassets.net/23aumh6u8s0i/6zJSQCmw0EmNkbhA8XppqK/9a4023bf1064087e70ad0459b0ffcb80/m2m-application-scopes)

After the form saves, you'll land on the details page for the newly created application.

To call the API using the app you just created, you'll first need to request an access token to include in your user import API call. To do so, open a terminal window and use the following cURL command, filling in your app's values for `YOUR_DOMAIN`, `YOUR_CLIENT_ID`, and `YOUR_CLIENT_SECRET`.

```bash
curl --request POST \
  --url 'https://YOUR_DOMAIN/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data `grant_type=client_credentials` \
  --data 'client_id=YOUR_CLIENT_ID' \
  --data `client_secret=YOUR_CLIENT_SECRET` \
  --data 'audience=https://YOUR_DOMAIN/api/v2/'
```

These values can all be found on your application's details page, under the "Settings" tab:

![settings tab on Auth0 application details page](https://images.ctfassets.net/23aumh6u8s0i/6GKcFxwf0VfaN2oemVR9Wm/2b69f5d6771fceafb16663f32dc48d4f/get-application-details)

> For an easy way to get the proper parameters set, you can go to the [Management API Docs](https://auth0.com/docs/api/management/v2/get-access-tokens-for-production#get-access-tokens) and sign in to copy the exact cURL request you'll need to request an access token.
>
> ![access token cURL command from Auth0 docs](https://images.ctfassets.net/23aumh6u8s0i/zr8zE0lx4Rkqa6H3HCbBr/ec086e4bf496760002c2aa85da6d542a/quick-start-token-from-docs)

With your token in hand, the next piece of information you'll need is the ID of your database connection. You can retrieve this with a request to the Management API's `connections` endpoint.

If you're going through the API, use the following command:

```bash
curl --request GET \
  --url 'https://johnbrennan.auth0.com/api/v2/connections?name=on-prem-migrated-users'
  --header 'authorization: Bearer MGMT_API_ACCESS_TOKEN'
```

You'll need to grab the `id` field from the JSON payload that's returned.

Now that you have the token and database ID, it's just a matter of making a cURL request to the Management API with your token and the JSON file of your users. Use the following command:

```bash
curl \
  -F users=@USERS_IMPORT_FILE.json \
  -F connection_id=CONNECTION_ID \
  -H 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
  https://johnbrennan.auth0.com/api/v2/jobs/users-imports
```

We're using cURL's `-F` flag as a shortcut for setting some basic properties; namely, setting the request type to `POST` and the `content-type` header to `multipart/form-data`.

Note that, when replacing `USERS_IMPORT_FILE` in the command above, you can either use your computer's absolute path to the user data file (e.g., `@/users/johnbrennan/documents/users.json`) or, if you're calling cURL from the same directory as the file, you can reference it as a local file (e.g., `@users.json`.)

If all goes well, you should get a JSON payload back as a response:

```json
{"type":"users_import","status":"pending","connection_id":"con_v70Bv0ocb8dwTf92","connection":"on-prem-migrated-users","created_at":"2020-03-20T04:56:19.475Z","id":"job_wnt1clHt6VpGs7Lx"}
```

This response indicates that a long-running job has been kicked off to import your users. You can check the status of the job by calling the `/api/v2/jobs/{id}` endpoint, using the `id` property from the JSON response above in the URL.

Once the job is complete, you can head to your Auth0 dashboard to see your imported users. Open the "Users & Roles" section in the lefthand menu and click "Users." Any user you've imported should show in the list; if you have multiple database connections in your Auth0 Tenant, you can filter users by their database connection in the search bar, selecting "Connection" in the "Search By" dropdown to the right of the text area.

![Auth0 users page using connection filter](https://images.ctfassets.net/23aumh6u8s0i/KwjGV6Qf5q7ttHAxTV2xj/ce8155a3c56f025decf6dae3d13c8bf0/filter-users-by-db-connection)

### Importing users via Import Users extension

The other option for Bulk Migration comes in the form of an [Auth0 Extension](https://auth0.com/docs/extensions) called [User Import/Export](https://auth0.com/docs/extensions/user-import-export). Extensions are &mdash; as the name suggests &mdash; scripts and applications that extend the functionality of Auth0. The User Import/Export Extension is built and maintained by Auth0, but it does require installing and authorizing it on your tenant.

To install the extension, head to your [Auth0 Dashboard](https://manage.auth0.com) and click "Extensions" in the left menu. Once on the page, type "import" into the search bar. The "User Import/Export" Extension should be the first result.

![Auth0 extensions page using name filter](https://images.ctfassets.net/23aumh6u8s0i/3X4sOsP1UaKzhE9nP0UQJY/cf0f06df82aa412a0aa7d7ae3250edbc/filtered-list-of-extensions)

Click the extension to open the confirmation screen for adding the extension to your account. Here, you'll see what scopes the extension is requesting on the Auth0 Management API. Click "Install" to start the process.

![Auth0 Extension installation form](https://images.ctfassets.net/23aumh6u8s0i/3ID8NSAyDVT0Ma5OnCXpzA/11cc71796bf9f7ab9cdb01f34d376b83/extension-installation)

Once installed, you can easily access the extension under the "Installed Extensions" tab on the main Extensions page.

![list of installed Auth0 extensions](https://images.ctfassets.net/23aumh6u8s0i/uebHdTsVMEwk5uGwLOtOo/cc2f4c1b6ff07ea9a6fb5d8795c5100d/installed-extensions-list)

You'll need to authorize the extension for use with your Auth0 account before using it. To do so, click on the extension's name to open the authorization screen:

![authorization screen for Auth0 extension](https://images.ctfassets.net/23aumh6u8s0i/ECTHNHFmvdcvqF0V1n2aT/83f6705903bef38c4719e44276407851/extension-authorization)

Once authorized, the extension provides a form from which you can upload your formatted JSON file containing user data.

![User Import Export extension upload screen](https://images.ctfassets.net/23aumh6u8s0i/7EBqQvRXECrak1E7Bk2sk9/dd0991349f308d4734dd28f92811c0e7/extension-upload-screen)

For a more comprehensive explanation of the extension and its capabilities, you can check out the [Auth0 Docs page for the User Import/Export Extension](https://auth0.com/docs/extensions/user-import-export).

## User Migration Strategy #2: Automatic Migration

If your current solution isn't immediately being deprecated, [Automatic Migration](https://auth0.com/docs/users/guides/configure-automatic-migration) is a convenient way to migrate users one at a time as they sign in.

As mentioned above, one key consideration with this solution is whether or not your existing identity solution is accessible from the public internet, which is required for Automatic Migration to work. If your user data isn't publicly available, you'll need to do some additional work to hook up a migration solution. Depending on your identity solution, one option is to create a reverse proxy (e.g., using NGINX or serverless functions) that's exposed to the public internet and will reformat and forward requests to your internal identity solution. The specifics are relatively complex and beyond the scope of this post, but we're planning a future post that explores this solution in detail!

Automatic Migration works by writing custom scripts, implemented in JavaScript, that call your existing identity provider's APIs when a user logs in to Auth0. When the script runs, Auth0 checks if the user exists in Auth0's database. If they do, they log in as expected. If they are not, the custom script calls the existing identity store to retrieve the user's information and store it in Auth0's database. This way, users are only migrated when they log in, meaning a seamless transition between identity providers.

![Diagram of Auth0 automatic migration logic](https://images.ctfassets.net/23aumh6u8s0i/52NQ04AL71R5z8aqnWFf5z/7e689450ddc6e170821744eacdb62cdf/migrating-diagram)

As mentioned above, the tradeoff in this approach is the amount of time it takes. Since user data migrates only as a user logs in, infrequent or dormant users may not have their data migrated to Auth0 in a reasonable amount of time.

If you have some time in your migration strategy, you also have the option of a two-stage approach to migration. This hybrid approach involves starting with Automatic Migration to move your existing active users over to Auth0 quickly and seamlessly, followed by bulk importing remaining users after automatic migrations slow down.

## Conclusion

Migrating your identity solution can feel like a daunting task. Even setting aside the business complexities, the act of retrieving user data from your existing system and moving it to a new one can present many logistical challenges. Auth0 aims to lower the complexity of this process as much as possible and, with multiple approaches to data migration, create a seamless experience for your customer base.


Technical Strategies for Migrating Users to Auth0

eugenio-pace-new-avatar

Pace co-founded Auth0 in early 2013 with CTO and “brother-in-arms” Matias Woloski while living 7,000 miles apart from each other. Since then, Pace has played an instrumental role in growing Auth0 into a leading identity management company that is loved by developers and trusted by global enterprises. He loves traveling and has visited more than 35 countries for business and pleasure. He currently lives in Redmond, Washington with his wife, two sons, and their labrador retriever. In his spare time, he enjoys the outdoors, rowing, riding bikes, spending time with his family, restoring his 1970 Karmann Ghia, writing his blog, and reading history and philosophy.

CEO and Co-Founder

Eugenio Pace

We are going to extend the scenario described in the previous post, so Fabrikom can accept users from another partner company.

We are going to extend the scenario described in the [previous post](http://blog.auth0.com/2013/03/04/On-Premises-SharePoint-Federated-with-Office-365-and-Google/), so Fabrikom can accept users from another partner company. This time, their users will authenticate with an on-premises Active Directory.

![Federation Active Directory](https://images.ctfassets.net/23aumh6u8s0i/1fdbyoES9mKToT95lBHwrF/920d1492721f4cc0e965c6f1bf46a1d5/auth0-sp-O365-ad)



Again, with Auth0 this is very simple. Because Fabrikom's SharePoint is already configured to use Auth0, all it needs to do is add a new connection with its partner's AD.

This short demo shows:

-1. John, an employee from Fabrikam's partner company, logs-in into SharePoint with his credentials.
-2. Notice how "home realm discovery" works. John enters his e-mail address in __Auth0 Login Widget__. As with the previous example, Auth0 will extract the domain and map it to the right Fabrikom connection (Active Directory in this case).

<iframe width="700" height="525" src="https://www.youtube.com/embed/xmGjp1pLbVE?rel=0" frameborder="0" allowfullscreen></iframe>

A frequent question we get is whether the login experience is extensible and customizable.

The __Auth0 Login Widget__ is designed to get you going quickly and is fully customizable. And is optional. You have full control of the login process.

For example, Fabrikom is likely to have a URL for its own employees (who generally wouldn't need a selector) and a different URL for partners (who will likely need the selector). Another popular option is to use vanity URLs, or something like:

>https://thesharepoint.fabrikom.com/ThePartner

All this is very simple to achieve with Auth0.

Another frequent question we get is: can the connection between Fabrikom and its partners be automated?

The automated/self-service provisioning is demonstrated in this [post](http://blog.auth0.com/2012/02/28/SaaS-App-Federated-with-Office-365/), using __Auth0 Provisioning Widget__.

The __Auth0 Provisioning Widget__ is using Auth0 API under the hood to create a new connection.

> __A final note of this example:__ the connection to Active Directory is done here through ADFS (Active Directory Federation Services). We assume that the partner has deployed it already. But what if the don't have it?
Auth0 provides you with __Auth0 AD Connector__. A simple component your partner would deploy and you are done with minimal intrusiveness.

[Try Auth0 yourself!](https://auth0.com)

On-Premises SharePoint Federated with Partner AD

Auth0 is about making identity simple. And even simpler for the most common and recurrent scenarios. One such scenario is a company that is using SharePoint

Auth0 is about making identity simple. And even simpler for the most common and recurrent scenarios.

One such scenario is a company that is using __SharePoint on-premises__ and has moved e-mail to __Office365__. They might not yet be ready for using SharePoint in the cloud (e.g. don't have the time for a migration to the cloud, or need more advanced customization than what Office365 offers).

![SharePoint Federation](https://images.ctfassets.net/23aumh6u8s0i/6eR38qGF4BlzozrierXIuk/8e4b6f32c1ef4440ccf202fdc02f77d0/auth0-sp-O365-goog)

With Auth0 this is straight forward, as we support SharePoint out of the box. You simply need 2 lines of JavaScript to initiate login (using __Auth0 Login Widget__).



![](https://images.ctfassets.net/23aumh6u8s0i/xdbrKOhApW8rIC83La6dE/f9ea85c2d3ccba435d28ad6ac9273915/auth0-sp-login-widget)

This has an additonal benefit: now you can also open your SharePoint to other organizations that need to collaborate with you. You don't need to create or manage their credentials yourself anymore.

This short demo shows exactly this scenario:

-1. Tom, an employee in Fabrikom logs-in into SharePoint with his Office365 credentials.
-2. A partner of Fabrikom, logs in with his Gmail account.

<iframe width="700" height="525" src="https://www.youtube.com/embed/QXpjouNt9XM?rel=0" frameborder="0" allowfullscreen></iframe>

In the next post we will cover a natural extension of this first scenario: federating with a partner company using Active Directory.

[Try Auth0 yourself!](https://auth0.com)

"on-premises"