Add User to Role in Authorization after initial sign up

Help
, ,
1

Hello,
I would like to use the Authorization module to be the source of truth for our users and roles mapping. I would like to implement the sign up flow so that after the user signs up, they are automatically added to one of the existing Groups already defined.

I would like to do this logic in a Rule. It can check to see if the (new) User is already in one or more Roles, if not then the Rule can use the API to add the User to a Role.

I basically want to use the “API” as referenced in the #1 answer in this question]1, but I can’t find what API to use inside a Rule. Are you able to point out the API or an example Rule? I see Rules that modify the user or app metadata, and also Rules that modify the payload of the id or access tokens being returned.

I want to do this as I already have Rules that will get the Roles and permissions based on the Roles the User is in and return the list of Permissions.

2

The API the answer in question is mentioning is the Authorization Extension API; you can enable it after installing the extension and once enabled the API is listed in the APIs section which would mean you can authorize client applications to call it.

Have in mind that the answer talks about two alternatives for a scenario related to initialize roles based on an external source and ideally the first option of using the API from a tool/migration script should be the one used as calling it from a rule will have some additional complexity.

3

OK, thanks for the info on enabling that API. In my use case, all information will reside within the Auth0 ecosystem. This includes users, roles, scopes, and permissions. It doesn’t logically make sense to have to make an API call to my system during sign up that would then just immediately make an API call back to Auth0 to make the Role assignment.

That is why I would like all the logic in a Rule. Why do you say there is extra complexity involved with calling the API from a Rule? I understand in the question I linked to they are using an external data source for Roles mapping.

4

Hey @mholtzman I believe we do what you’re trying to do, but let me list it to see if you agree:

  • When user logs in successfully the
    first time, store date/time in
    app_metadata so that subsequent rules
    can use this info. Note: we don’t
    assign a role (in our case) when user
    signs up, but only after successful
    log in
  • Load Auth0 authorization
    extension (built in rule from Auth0)
  • Custom rule: if user does not have
    role, call auth-ext (via REST) to
    assign default role
  • Custom rule: if default role was just assigned, re-load auth-ext
  • Custom rule: add roles/permissions to access_token
3 Likes
5

Thanks @joe.tillotson that logic is basically what we are after.

A couple of questions, why can’t bullet points three and four be a single rule? It seems like if the rule know to make the rest api call to add the default role, then it can also reload auth-ext.

Is the signup time stamp added to the app metadata used for other logic in your app as it doesn’t appear to be used in these rules?

Thanks for the logic, I’ll give this a shot.

6
  1. 3 and 4 could be a single rule but I like to keep each rule limited to a single responsibility so to speak. Just a style choice.
  2. Yes, “firstLoginDateTime” (which again, is not when they signed up, but when they first log in successfully) is used to determine which account is the “link-er” and which is the “link-ee” when we (potentially) link accounts (i.e. same email). For social accounts (e.g. Google) then ‘signup’ and ‘first login’ are the same thing. For a db connection ‘email account’, we treat these accounts differently before/after they verify their email address.
7

I think I just about have this working, but I am getting an error making the PATCH call to add the Role to the User. I am getting an HTTP 403, insufficient scope.

I noticed when I enabled the authorization extension API, the API that was automatically created did not include a scope for update:users which is required for that API call. The only users scope it automatically created was read:users. I manually created a scope for update:users and assigned it to the non-interactive Client, still doesnt work.

8

I figured out this issue, there is an error in the docs. They say for the API the scope required is: update:users, you actually need update:roles

https://auth0.com/docs/api/authorization-extension?http#add-user-to-roles

1 Like