Setting up Auth0 for your full-stack Angular SPA

Auth0 offers Security-As-A-Service for your full-stack Angular SPA

The high-level architecture

Feedback Pal high-level architecture

Setting up Auth0

Auth0 is a Security-As-A-Service product. It comes with a generous free tier which you can leverage to learn more about it.

Setting up your SPA application

Signup to Auth0 to get your tenant. Then, set up your SPA application.

Click on the “Applications” menu on the left, then on the “Applications” link and finally create a new application. Make sure you choose SPA (Single Page App) as application. You can call it whatever you want. I’ve named mine Feedbackpal.

First part of the Auth0 application setup

To get your Angular frontend to use Auth0 for user’s authentication, you will need the Client ID. This is not sensitive data, as per Auth0 documentation.

You are in control of which domains can use Auth0

If you keep scrolling down, you will find a section where you can add the authorised URLs which will invoke Auth0 to securely login users. A section of my app setup looks like the following:

Allowed client URLs

As you might notice, I’ve added both localhost.x URLs, for when I test my app locally, as well as URLs of the production environment my application is running in.

Finally, in the ID Token section at the bottom of the page, you can set up things like token expiration, whether to enable token rotation, etc. My section looks as follows:

IT Token setup

When done, you can click “Save Changes”.

Setting up your Social connections

Next, you will need to decide which Social Provider users of your application can use to login. Under the “Authentication” menu, select “Social” and then setup your social providers of choice. My setup looks like the following:

Setting up the roles for your application

Next, you might want to setup the roles containing the permissions for your application. For Feedback Pal, I’ve setup two roles:

  • feedbackpal-admin. This role contains all the roles for the feedbackpal-user but in addition it contains the admin role.
  • feedbackpal-user. This is the default role that we’ll need to assign to each user signing up to your application.
List of Feedback Pal roles
Permissions are fundamental for a backend API

When you setup a new role, you can assign permissions. The convention in Auth0 is to use permission:resource. Here is an example of how I setup the feedbackpal-user roles:

feedbackpal-user permissions

And for the feedbackpal-admin role:

feedbackpal-admin permissions

We will see later how these roles are used.

Setting up the Auth0 Authorisation Extension

Next, you’ll need to setup the Authorisation Extension. From the “Extensions” menu, click on “All Extensions” and select “Auth0 Authorization”. Here we pretty much need to setup the same roles and permissions as above. The difference here being that these permissions will be used when the SPA client exchanges an ID Token for a JWT token, before invoking the backend API.

In my setup, I’ve defined the same roles as mentioned above as well as the same permissions for each role.


Here, you can also assign a specific role to a particular user. For example, I’ve assigned the feedbackpal-admin role to my user. For all other users, we’ll assign the feedbackpal-user role upon users signup. We will do this through Auth0 rules, which we’ll look at later on. My roles look like the following:

Auth0 Authorisation extension roles

My extension permissions look like the following:

Auth0 Authorisation extension permissions

Assigning an admin user

As mentioned above, you’ll want to setup the users having the role of feedbackpal-admin. From the “User Management” menu on the left, select “Users” and for each admin, assign the admin role you’ve setup above. In my case, I’ve assigned to myself the feedbackpal-admin role, which gives me all permissions of a regular Feedback Pal user plus the admin:feedbackpal role.

Setting up the backend API Authenticator

Next thing we need to do is to setup the API Authenticator. As mentioned earlier when users login to your SPA frontend, they get an ID token, which the frontend can use to verify that a user is authenticated. Later on we will see how Angular can use some libraries provided by Auth0 to automatically get the users to login/signup or to inspect whether a user is logged in. This, combined with Guards, allows to offer users a rich interactive experience, by showing / hiding features based on their security status.

Create the API

For now, let’s head up to the “Application” section again and click on APIs and then create an API. You can name your API as you wish. I’ve named mine Feedbackpal API. In here, the single, most critical piece of information you need to provide is the API identifier. You can name this as you wish. Auth0 convention is to have it in form of a URL. The URL must not exist for you to be able to define an Identifier. I’ve called my one There isn’t any endpoint for this URL, it’s just a name, but when setting up your application, you’ll need to use the identifier as an “Audience”. We will see how that works. My API Settings look like the following (blurring data I don’t want to share):

Auth0 API Settings – 1
Auth0 API Settings – 2
Enabling RBAC is fundamental for a correct JWT token

It’s important that you enable RBAC as well as adding the permissions to the Access Token. When the Angular client needs to make calls to the backend API, it will exchange an ID Token (used for SPAs) with a JWT token (used by the backend API). Auth0, upon looking at the users logged in and their roles, it’ll add these roles to the JWT token. The backend API will then be able to extract these roles from the JWT token (using Auth0 libraries we will look at later) and make these roles available to Nest JS Guards. This way any API resource is protected against specific roles required to execute that operation.

Next, you’ll need to setup the permissions (scopes) of your API. Surprisingly enough, I’ve set these up exactly as all others.

API Permissions (scopes) setup

We’re nearly done with the Auth0 setup. The last two things we need to do are to:

  • Setup the Auth0 rules to prepare the JWT tokens as we want to use them in the API
  • Setup the login screen for the SPA application. This is what users will see when logging in / signing up to your application.

Setup Auth0 Rules

Rules can be used for many things. For the setup of Feedback Pal, I’ve setup the following rules:

Auth0 Rules

Please note that Auth0 automatically creates some of these rules and the order is important. For example, when we setup the Authorisation Extension, Auth0 automatically created the first two rules.

The “Assigns default role to signed up users” Rule

I’ve created the third and fourth rule. The third rule is to assign the feedbackpal-user role automatically to users when they signup. Since this role contains all the permissions we’ve set up earlier, upon signup Auth0 assigns this default role to users.

function (user, context, callback) {
  	const ManagementClient = require('auth0@2.27.0').ManagementClient;

    const management = new ManagementClient({
      token: auth0.accessToken,
      domain: auth0.domain
    const count = context.stats && context.stats.loginsCount ? context.stats.loginsCount : 0;
    if (count > 1) {
        return callback(null, user, context);

    const params =  { id : user.user_id};
    const data = { "roles" : ["rol_Ed260sBo6vhZZOlt"]};

    management.users.assignRoles(params, data, function (err, user) {
      if (err) {
        // Handle error.
    callback(null, user, context);
Roles might not be as easy as you think…

There’s something tricky here. Something I hope Auth0 will resolve in future. If you notice the statement when we set the “data” variable, the role name is not feedbackpal-user, rather a very long and strange string. It turns out that to make this rule work, we need to use the Auth0 internal name assigned to the feedbackpal-user role, not its logical name. To find this, head out to “User Management -> Roles”, click the feedbackpal-user role and then look in the Web Browser address bar for the internal role name.

How to get the role identifier to add to the Auth0 rule

The part of the URL containing rol_… up to the next forward slash is the name to use in this rule. It’s very important that you specify the correct role name or this rule will fail, your users won’t get assigned a default role containing the permissions required by the API backend and your application won’t work.

What if I want more user data in the JWT token?

The last Rule I’ve created is to add the user’s email to the JWT token when Auth0 generates it.

A rule to add the email address to the JWT token.

If you don’t need your user’s email in the JWT, you can omit this rule. If you go ahead, Auth0 convention is to use a namespace to contain custom user’s attributes. We will see later, during the discussion on how to handle the JWT token in Nest JS, how the API backend can extract this information from the JWT token.

For now, I’ve decided that the user’s email will be contained in the following property within the JWT token:


The last thing left to do is to setup how your login/signup screen (The Login Box) will look to the users.

Click on “Getting Started” and then within the “Try your Login box”, click on “Customise”.

Login box
Login box customisation

Here you can add your company logo, select which Login Box template you prefer, etc. I’ve just selected the New look and feel and added a Company Logo.

That’s it! You’ve now setup Auth0 to handle both your Angular frontend and Nest JS API backend end-to-end security. Now let’s see how the frontend SPA works.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.