I’d like to add a default employee role to users with a given email domain whenever they register in my Auth0 tenant via my SPA. I believe I’d want to only grant the role once the email has been verified on the account however.
I’m familiar with and have seen various posts articles on both how to check for email verification when a user is logging in, and granting a role to a user post-registration based on their email.
The issue I see with this is that presumably I cannot check for email verification before adding the user role in the post-registration action - because the user would not have had time to receive and click on the verification link.
With that in mind, where (if anywhere) within the Auth0 flows would I be able to add a user role while being able to sensibly check for email verification in this way? I thought there might be a hook/flow/etc. that occurred post-email-verification, but haven’t seen anything.
I understand that you would like to add a role to a new user with a specific email domain provided that their email has been verified.
In this situation, I recommend using a Post-Login Action script to add a role to the user only if their email has been verified and matches a specific domain.
Because we are using a Post-Login Action script and would like to only assign the user role once, we should include a user_metdata check for a single execution. Here is an example:
exports.onExecutePostLogin = async (event, api) => {
if (!event.user.email_verified || !event.user.email.endsWith("@example.com")){
api.access.deny(`Access to ${event.client.name} is not allowed.`);
}
if(!event.user.user_metadata.assignedRole){
const ManagementClient = require('auth0').ManagementClient;
const management = new ManagementClient({
domain: event.secrets.domain,
clientId: event.secrets.clientId,
clientSecret: event.secrets.clientSecret,
});
const params = { id : event.user.user_id};
const data = { "roles" : ["ROLE_ID"]};
try {
const res = await management.assignRolestoUser(params, data)
api.user.setUserMetadata("assignedRole", true)
} catch (e) {
console.log(e)
// Handle error
}
}
};
Here are some helpful resources you may find relevant:
I have a question regarding this. I am doing something similar, but at the same time use the role / permission embedding in the token. How can I refresh the token the auth0 will send to client after I have assigned the new role?
Thanks for the reply, unfortunately I don’t thinks that’s going to cover all the cases. Considering the below:
The Post-User Registration extensibility point is available for database connections. To learn more, see Database Connections.
and the fact that I am using Google Login in between others?
The other caveat is that most of the system is ready and relies on the permissions being in the regular place where auth0 tokens hold them. I would really like to avoid bloating the tokens (through putting lengthy permissions array in two places) any further at this point, especially the possible permissions duplication if I do it in customClaims. I do know I could do it this way, but what I am after is getting the permissions into the top level permissions field.
"permissions": [
Also I am seeing this happen properly for the Passwordless users - that is even if it’s a new user that hits my logic for assigning a role the token I receive in the app contains the Permissions that auth0 is loading.
What I don’t understand is why does this not happen for Google / Social users.
Firstly, a Database or Social Connection will work with a Post-Login Action. Moreover, the examples shown in this link and my previous post are a Post Login Action. I am not seeing where a Post-User Reg is involved.
In this sittuation, you will need to toggle off the feature that Adds permissions in the Access Token and create a Post-Login Action to add the user’s permissions and roles to the token. This will avoid doubly adding the permissions and roles if you previously had the Adds permissions in the Access Token toggle enabled. See below for clarity:
You will not be able to populate the permissions array in the access token unless the user was previously assigned permissions before granting the access token, or you will need to configure silent authentication to request a new access token with the newly populated permissions.
I would recommend the former, where you add the permissions/scopes as a custom claim to the access tokens before granting the access token.
Please let me know how this goes for you. If you need further assistance on getting the Action working, please feel free to reach out.
