Create a Tenant and Learn the Basics

We will walk through the initial steps of getting started using Auth0 to familiarize you with the key concepts of the Auth0 service. We will use the company Example-Co to help describe some of the steps involved.

If you haven't already signed up for an Auth0 account, do so (it's free). You can either use username and password or log in with a social provider (such as Facebook, Google, or Apple).

Create a tenant and domain

Once you create your account you will be asked to create a tenant. Everything starts with an Auth0 tenant. This is where you configure your use of Auth0, and the where Auth0 assets - such as applications, connections, and user profiles are defined, managed and stored. You access an Auth0 tenant via the Auth0 Dashboard, where you can also create additional, associated tenants. You can create more than one Auth0 tenant so that you can structure your tenants in a way that will isolate different domains of users and also support your Software Development Life Cycle (SDLC).

Tenant names cannot be changed or reused once deleted. So, make sure you're happy with the name(s) before you create your Auth0 tenants.

Determining the level of isolation you require when it comes to your user domains is an important step, and together with your branding requirements helps you determine the number of Auth0 tenants needed in your environment. The number of Auth0 tenants you need to manage can quickly grow so consider carefully before creating multiple Auth0 tenants for production.

Tenant characteristics:

The tenant name has to be unique. It will be used to create your personal domain.
The tenant name can contain only lowercase alphanumeric characters and hyphens ("-"). It cannot begin or end with a hyphen.
The tenant name must be a minimum of 3 characters and a maximum of 64 characters.
The tenant name cannot be changed after creation.
You can create more than one tenant; in fact, you are encouraged to do so for each environment you may have such as development, staging, or production. See Set Up Multiple Environments for details.

When you name your tenant, that name becomes your Auth0 domain. (Or, you can create a custom domain; see below.) This domain is the base URL that you will use to access our API and the URL where your users are redirected in order to authenticate. Auth0 supports three regional subdomains:

us.auth0.com for US
eu.auth0.com for Europe
au.auth0.com for Australia

Tenants created on or after 10 June 2020 in the US region will be appended with us.auth0.com (instead of auth0.com) to create the domain URL that you use to access Auth0 services.

When you are asked for the region you want to use, your choice affects which regional subdomain will be assigned to you and where your data will be hosted. If you pick US then the name format will be YOUR-TENANT-NAME.us.auth0.com, for Europe it will be YOUR-TENANT-NAME.eu.auth0.com, and so forth.

In our example, Example-Co chose the name example-co and US as their region. So their domain is example-co.us.auth0.com.

Custom domains

We recommend the use of custom domains, such as example-co.com, in production environments to provide your users with the most secure and seamless experience. This comes with an additional cost.

If you have a single-tenant implementation, you can deploy your custom domain in:

The cloud-managed by Auth0
An AWS cloud managed by you

See Custom Domains for details.

Now that you have an account and a domain, you need to register each application that will use our services in the Auth0 Dashboard. We use the term application as OAuth 2.0 does. The first piece of information we ask for is its application type. This can be one of the following:

Application types you can choose when looking at quickstarts: Native/Mobile App, Single-Page App, Regular Web App, Backend/API

Auth0 assigns each application a Client ID, an alphanumeric string, which is the unique identifier for your application. For example, q8fij2iug0CmgPLfTfG1tZGdTQyGaTUA. You will use this ID in your application code when you call Auth0 APIs. You can't modify the Client ID.

Another important piece of information is the Client Secret. Think of it as your application's password which must be kept confidential at all times. If anyone gains access to your Client Secret they can impersonate your application and access protected resources.

In our example, ExampleCo has two applications: a web app (running on a server) and a mobile app. They would create two applications:

a regular web app
a native app

See Applications in Auth0 for details.

Now that you have set up your Applications, you are ready to configure how your users will log in. Auth0 sits between your app and the identity provider that authenticates your users (such as Google or Facebook). The relationship between Auth0 and the identity provider is referred to as a Connection. By using this connection layer, Auth0 keeps your app isolated from any changes that occur with the identity provider's implementation.

Connections are sources of user data and they can be of the following types:

Connection	Description
Database	Auth0 cloud database or your own database containing usernames and passwords
Social logins	Google, Facebook, GitHub, Twitter, etc.
Enterprise directories	LDAP, G Suite, Office 365, ADFS, Active Directory, SAML-P, WS-Federation, etc.
Passwordless systems	SMS or email one-time codes

You can share connections among applications and you can configure any number of connections, then choose which to use with an application.

In our example, ExampleCo wants its users to be able to login with username/password, Google, and GitHub, both from the web app and from the mobile app. Therefore, the steps to follow would be:

Configure a database connection.
Configure the Google connection.
Configure the GitHub connection.
Enable all three connections for the web app.
Enable all three connections for the mobile app.

Auth0 offers several ways to extend the platform's functionality:

Rules: Rules are functions written in JavaScript or C#, that are executed in Auth0 just after successful authentication and before control returns to your app. Rules can be chained together for modular coding and can be turned on and off individually. You can use rules for:
- Access control
- Webhooks
- Profile enrichment
- Multi-factor authentication (MFA)
Hooks: Hooks allow you to customize the behavior of Auth0 using Node.js code that is executed against extensibility points (which are comparable to webhooks that come with a server). They are secure, self-contained functions associated with specific extensibility points of the Auth0 platform. Auth0 invokes the Hooks at runtime to execute your custom logic.
Extensions: Auth0 Extensions enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product. You can either use one of the pre-defined extensions, provided by Auth0, or create your own. Some of the actions you can do with extensions include:
- Manage the authorizations for users (using groups, roles, and permissions)
- Import/export users
- Export logs to other services
- Deploy scripts from external repositories

Docs