Authenticate: SPA Example

In part 1, we described a few of the ways that you can provide services to your users through your applications using user authentication. 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 Multi-factor Authentication (MFA).

In this video, we will look at how the Quickstart single page application or SPA implementation uses Universal Login—which is the preferred method for authentication workflow in Auth0.

You can find the quickstarts at https://auth0.com/docs/quickstarts. It is a good idea to login to a specific tenant. Here I am using the product-training tenant. This will make the user experience better later on.

Next, we need to select the type of application we want to use. We can start with single page application. Then select the vanilla javascript quickstart.

Here we are offered two options; the first is a detailed step-by-step guide to implementing authentication in an existing javascript application, and the second is to download a fully functional sample application.

Let’s download the sample application. Because we are authenticated, the quickstart download gives us an option to select an existing application from our tenant. The downloaded sample application will be configured to use this applications credentials for authentication.

We are also instructed to add our localhost development url to the Callback URL and Allowed Web Origins lists.

Finally, assuming that node.js is installed we can install our dependences and start the application.

Now we can test the authentication by clicking the Login button.

Now that we have an application connected, let’s take a look at Universal Login. You can choose from Classic or New to create your own login pages that will authenticate your users. Later in another video, we will show you how to provide more extensive branding for these pages and more.

The buttons that appear on the login page depend on a number of factors including the connections that have been enabled and the current state of a session the user may already have. These settings are dynamic and adjustable in real-time—no coding changes are required—since the functionality is driven by the web pages served by the Auth0 Authentication Server.

If you have Enable seamless SSO enabled or if you have a new tenant, where this option is enabled by default and can’t be turned off, Auth0 will show the login UI only if the user doesn’t have a session. There may or may not be other prompts as well like MFA or consent, but if no user interaction is required then the application will get the results immediately. Therefore, in most cases, applications don’t really check if the user is logged in into the identity provider: they just request an authentication.

Universal Login works by effectively delegating the authentication of a user; the user is redirected to the Authorization Service, your Auth0 tenant, and that service authenticates the user and then redirects them back to your application. In most cases, when your application needs to authenticate the user, it will request authentication from the OIDC provider, Auth0, via an /authorize request. As you can see from the quickstart, the best approach to implementing this is to use one of the language-specific Auth0 SDKs or some third-party middleware applicable to your technology stack. How to actually do this depends on the SDK and application type used.

Once authenticated, and when using an OIDC authentication workflow, Auth0 will redirect the user back to your callback URL with an ID token or a code to fetch the ID token.

For OIDC, Auth0 returns profile information in the ID token in a structured claim format as defined by the OIDC specification. This means that custom claims added to ID Tokens must conform to a namespaced format to avoid possible collisions with standard OIDC claims. For example, if you choose the namespace https://foo.com/ and you want to add a custom claim named myclaim, you would name the claim https://foo.com/myclaim, instead of myclaim.

By choosing Universal Login, you don't have to do any integration work to handle the various flavors of authentication. You can start off using a simple username and password, and with a simple toggle switch, you can add new features such as social login and multi-factor authentication.

Next, we’ll see how easy it is to integrate Auth0 in your second application. If you run another quickstart, for example, to integrate a web application, you don’t have to do anything else. Running the second quickstart against the same tenant will configure SSO between your applications automatically.

Let’s download another quickstart and see this in action.

This time around, I will select the Regular Web App application type and asp.net core sample. Asp.net core is a typical enterprise server side rendered web application framework.

The steps are the same as before: Select the application, set local development urls, download and run the sample.

After authenticating the user and redirecting them to an identity provider, you can check for active SSO sessions.