Create Tenants
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.
Set up an Auth0 account
If you haven't already signed up for an Auth0 account, do so (it's free). You can either use username/email/phone and password or log in with a social provider (such as LinkedIn, Microsoft, GitHub, or Google).
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 then 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).
![](http://images.ctfassets.net/cdy7uua7fh8z/3aqUs6NTb69YhxZt0lpL4f/4c143e071a08cd7a8052b5e4db46e7da/image-20240621-221859.png)
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 63 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. To learn more, read Set Up Multiple Environments.
When you name your tenant, that name becomes part of your Auth0 domain until and unless you create a custom domain. This domain is the base URL used to access the Auth0 API and the URL where your users authenticate.
Region, locality, and sub-locality
The domain name is also made up of the locality value from a region. We support the following locality values for the public cloud deployment option:
Region | Locality | Sub-localities |
---|---|---|
Australia | AU | AU |
Canada | CA | CA |
Europe | EU | EU, EU-2 |
Japan | JP | JP |
United Kingdom | UK | UK |
United States of America | US | US, US-3, US-4 |
Each of these localities is separated into a sub-locality (or tenant environment) with a digit after the locality, e.g. EU-2
. Tenant environments cannot be chosen manually, but localities based on the selected region may be specified, which control the assigned tenant domain and the region where your data will be hosted.
In our example, Example-Co chose the name example-co
and AU as their region. So their domain is example-co.au.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
To learn more, read Custom Domains.
What's next
Create and register applications: Now that you have an account and a domain, you need to register each application that will use our services in the Auth0 Dashboard. To learn more, read Applications in Auth0 and Create Applications.
Set up connections: Next, you need to set up how your users will authenticate during 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. To learn more, read Authentication and Authorization and Connections.
Extend Auth0's functionality
Auth0 offers several ways to extend the platform's functionality:
Actions: Actions are secure, tenant-specific, versioned functions written in Node.js that execute at certain points within the Auth0 platform. Use Actions to customize and extend Auth0's capabilities with custom login.
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