Question about registering users with different roles

I’d like to create a site that has two unique sets of users. One would be “Coaches” and the other would be “Students”. What is the best way of registering these users using Auth0?

Hi @aspiringpro,

Have you looked into RBAC?

@dan.woda Yes I was reading about it but how would I assign the role to a user during a registration flow? I’m thinking I would have a multi step form where if a user wanted to register, they would first answer a question like “Are you a coach or a student?” and then proceed from there.

Got it. Here is how I would proceed:

You could use RBAC for this, and to do so you will have to take the metadata, then assign the user a role based on that info, kind of like this example:

RBAC will provide a built in UI for managing roles, but is more intended to setting up permissions with an api. If that is something you are doing, then use RBAC, otherwise metadata will be a little lighter weight. Either one will work here.


I was able to add the select option to the lock but am confused as to the second step of adding the metadata to the id token. I noticed that when I run my app, and I try to register, the user is registered and the metadata is there but now it does not log the user in. Where do I add the custom claim rule? My app code is visible at

You will add this rule in the Auth0 Dashboard under Rules.

Let me know if this helps.


So this is the code that I added as a rule.

function (user, context, callback) {
  const namespace = 'http://localhost:8080';
  context.idToken[namespace + 'usertype'] = user.usertype;
  callback(null, user, context);

Does that look correct?

You will need to reference the metadata like this:

function (user, context, callback) {
const namespace = ‘http://localhost:8080’;
context.idToken[namespace + ‘usertype’] = user.user_metadata.usertype;
callback(null, user, context);

You can use whatever you want for the namespace as long as it follows namespacing rules.

How do I check for coach or student in the id token from my app?

Which technology or SDK are you using? auth0-spa-js or auth0.js or something else?

Generally, the ID token is a JWT which can be decoded and it contains the custom claim such as usertype that’s been added in a rule. But depending on the Auth0 SDK you’re using, there are probably already sufficient helper methods available to make this lookup easy.

I am using auth0-js. Once again, my code can be viewed at

Here is my store.js file:

import Vue from 'vue'
import Vuex from 'vuex'
import auth0 from 'auth0-js'
import router from './router'


export default new Vuex.Store({
state: {
auth0: new auth0.WebAuth({
  domain: process.env.VUE_APP_AUTH0_CONFIG_DOMAIN,
  clientID: process.env.VUE_APP_AUTH0_CONFIG_CLIENTID,
  redirectUri: process.env.VUE_APP_DOMAINURL + '/callback',
  responseType: process.env.VUE_APP_AUTH0_CONFIG_RESPONSETYPE,
  scope: process.env.VUE_APP_AUTH0_CONFIG_SCOPE,
mutations: {
setUserIsAuthenticated(state, replacement){
  state.userIsAuthorized = replacement;
actions: {
console.log('In a store action');
  console.log('In a store logout action');

// redirect to auth0 logout to completely log the user Out

window.location.href = process.env.VUE_APP_AUTH0_CONFIG_DOMAINURL + "/v2/logout? 
returnTo" + process.env.VUE_APP_DOMAINURL + "/&client_id=" + 
auth0HandleAuthentication (context) {
  context.state.auth0.parseHash((err, authResult) => {
    if (authResult && authResult.accessToken && authResult.idToken) {
      let expiresAt = JSON.stringify(
        authResult.expiresIn * 1000 + new Date().getTime()
      //save the tokens locally
      localStorage.setItem('access_token', authResult.accessToken);
      localStorage.setItem('id_token', authResult.idToken);
      localStorage.setItem('expires_at', expiresAt);

    else if (err) {
      alert('login failed. Error #KJN838');
1 Like

With your rule above in place, It should be in


By the way: it’s best practice, for security reasons, to not store the tokens in localStorage or sessionStorage, actually don’t store them at all on the client side. Use silent authentication (via checkSession method) instead to request a new one on i.e. browser reload. See:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.