Authenticate: How It Works
Learn about the difference between authentication, authorization, and access control. Understand when and why you might use each type of authentication method: first factors, second factors, and multi-factor. Learn about the OpenID Connect (OIDC) authentication protocol.
Was this video helpful?
Before you can provide services to your users through your applications, you need to identify who they are, and that process is called user authentication.
In this video, we will show you a few ways to go about this. For example, you can authenticate users via their social media accounts or with their usernames and passwords. You can add an additional level of certainty about their identities with a second authentication factor; this is called Multi-factor Authentication (MFA).
Before you start, think about security and user experience, if you want to offer multiple primary authentication methods, and if you want to add multi-factor authentication. Planning how you want the authentication process to work before you do the steps required to implement the actual authentication is critical because it will determine how you configure your application integration.
One way to make sure you’ve considered all your authentication requirements is to adopt an iterative release style. For example, you may have three or four applications you need to integrate and, instead of tackling them all at once, you can make a series of iterations, tackling one application at a time. This way your teams can benefit from the experience, and you can leverage this approach to help increase velocity with each iteration.
Authentication, authorization, and access control
It’s important to distinguish between Authentication, Authorization, and Access Control. Your Auth0 tenant, the Authorization Server, is responsible for Authentication and some or all of Authorization. Access Control is the responsibility of the API or Application itself because access control is almost always contextual.
So, to summarize:
- Authentication is the process of determining if the user is who they say they are
- Authorization is declaring what that user is allowed to do in the system
- Access Control is limiting a user to only perform actions they are allowed to do based on a combination of their identity, their authorization information, and their consent.
In this video, we are only going to focus on authentication, we will address the other options such as MFA in a separate video. There are different types of connections you can make in the Dashboard that will enable authentication.
You can choose from among many social connections including the most commonly used ones like Google and Facebook. Choose connections that your users will most frequently have accounts with.
If you have more than one application, you will almost certainly want to have Single Sign-On between those applications. This is one of the easiest ways to give your users a good user experience without compromising on security.
As you may already know, the OpenID Connect specification—or OIDC—is the most widely used industry-standard authentication specification when it comes to customer-facing applications. It is intended as a way to provide SSO between applications. OIDC is based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens—or JWT—that you obtain using flows conforming to the OAuth 2.0 specifications. When a user signs in using their Google account, then they’ve used OIDC.
We’ve made it easy to enable this type of authentication with Universal Login. The way this works is you delegate the authentication of a user by redirecting them to the Authorization Service, your Auth0 tenant, and that service authenticates the user and then redirects them back to your application.
If each of your applications does this then Auth0 remembers whether the user has already logged in and sends them back to the new application without requiring them to re-enter their credentials. This is how we accomplish Single Sign On.
The next step is to figure out how to do this in your application. To help you out we’ve provided some guides to help you get started.
Before figuring out which quickstart to use, it is important to figure out which one most closely represents your application. You answer two questions to make this determination:
- What type of application do you have? Do you have a traditional web application, a single page application, or a native mobile application?
Was this helpful?
- Are you going to need an access token to call a separate API? If your application needs to call a separate API, then you will need to do some extra work after the quickstart to enable your SDK to get you an access token. You can learn more about that in the video that discusses Authorization.
Authenticate: SPA Example
An example using the Auth0 Quickstart for a SPA implementation with Auth0 Universal Login.
Authorize: ID Tokens and Access Control
What an ID Token is and how you can add custom claims to make access control decisions for your users.
Authorize: Get and Validate ID Tokens
How to get and validate ID Tokens before storing and using them.
What user profiles are, what they contain, and how you can use them to manage users.
Brand: How It Works
Why your branding is important for your users and how it works with Auth0.
Brand: Sign Up and Login Pages
How to use Universal Login to customize your sign up and login pages.
Brand: Emails and Error Pages
How to use email templates and customize error pages.
How to configure different kinds of user logout behavior using callback URLs.
Architect: Your Tenant
What an Auth0 tenant is and how to configure it in the Auth0 Dashboard.
Provision: User Stores
How user profiles are provisioned within an Auth0 tenant.
Provision: Import Users
How to move existing users to an Auth0 user store using automatic migration, bulk migration, or both.