Learn the Basics

Often, the biggest barrier to learning new things, especially in the tech industry, is terminology. The words that are used to describe things can cause problems when you try to understand new concepts. This document explains some of the basic terminology we use here at Auth0, and maps these terms to concepts you are already familiar with.


This article uses an example to introduce some core concepts of Auth0: accounts, tenants, domains, clients, and connections. If you already know what these are (in the context of Auth0) you can safely skip reading it.

We will use a very simple example: A company named Example-Co wants to use Auth0 for authentication. They have a web app and a mobile app, and they want their users to be able to login with username/password, Google, or GitHub.

Account and tenants

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

Once you create your account you will be asked to create a Tenant. This is a logical isolation unit.

The term is borrowed from "software multitenancy". This refers to an architecture where a single instance of the software serves multiple tenants. No tenant can access the instance of another tenant, even though the software might be running on the same machine (hence the logical isolation).

Some characteristics:

  • The tenant name has to be unique (we will see in the next paragraph that it is used to create your own personal domain).
  • 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 have (such as Development, Staging, or Production).
  • If you chose to host your data in Europe or Australia, then your tenant will have a suffix (eu or au). In our example, if Example-Co picked the name example-co, then depending on where the data is stored, the tenant name would be example-co-eu or example-co-au.


As discussed in the previous section, when you create a new account with Auth0, you are asked to pick a name for your Tenant. This name, appended with auth0.com, will be your Auth0 Domain. It's the base URL you will be using when you want to access our API (for example, to authenticate a user). The name format is TENANT-NAME.auth0.com (you get to pick the TENANT-NAME part).

In our example, Example-Co picked the name example-co; hence their domain is example-co.auth0.com.

Custom Domains

You can use a custom domain, such as example-co.com. This comes with an additional cost. This feature is in beta for public-cloud tenants (see the Custom Domains documentation for details). If you have a single-tenant implementation, you can deploy your custom domain in one of three locations:


Now that you have an account, we need to know about your app(s) that will be using our services. To that end, you must register each application. We use the term client to refer to an application (like OAuth 2.0 does).

When you create a client in the Dashboard, the first piece of information we ask for is its type. This can be one of the following.

Client Types

Each client is assigned a Client ID upon creation. This is an alphanumeric string and it's the unique identifier for your client (such as q8fij2iug0CmgPLfTfG1tZGdTQyGaTUA). It cannot be modified and you will be using it in your application's code when you call Auth0 APIs.

Another important piece of information is the Client Secret. Think of it as your client'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 apps: a web app (running on a server) and a mobile app. Hence, they would create two clients: one of type Regular Web Applications, and one of type Native.

We won't get into details on how to create a client, since this article is meant to provide a high level overview. However, if you want to know more, refer to the Clients documentation.


Now that you have set up your Clients, you are ready to configure how your users will login.

Auth0 sits between your app and the identity provider that authenticates your users (such as Google or Facebook). Through this level of abstraction, Auth0 keeps your app isolated from any changes of the provider's implementation.

This relationship between Auth0 and the identity provider is referred to as a Connection.

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

Each connection can be shared among multiple clients. You can configure any number of connections, and then choose which of them to enable for each client.

In our example, ExampleCo wants their 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:

  1. Configure a GitHub connection
  2. Configure a Google connection
  3. Configure a database connection
  4. Enable all three connections for the web app client
  5. Enable all three connections for the mobile app client

For more information on the supported identity providers, refer to Identity Providers Supported by Auth0. For details on how to enable a connection for a client, refer to Client Connections.

Where to go from here

In this article you familiarized yourself with several core concepts of Auth0. We used a simple example that added authentication to a couple of different apps.

If you wish to learn more about the next steps in setting up Auth0, you can read more:

  • Hook Auth0 up to your app: Assuming that your app has a login and a logout button, you need to add some code in order to invoke Auth0 APIs each time one of these buttons is clicked. For details you can refer to one of our quickstarts. Alternatively, you can directly call our API to log in or log out a user, or implement one of Auth0's libraries and SDKs.

  • Migrate your users to Auth0: If you already have a user store, you need to migrate these users to Auth0 before you go live. For more information refer to User Migration. Alternatively, you can connect your app to your own user database and access it via Auth0.

Keep reading

Take me Home
Getting Started
Next Tutorial
Dashboard Overview

Was this article helpful?