Rules - Auto account linking results in no access to roles

Help
, ,
1

Hopefully someone can help.

Our new user flow is this:

  1. We create a email passwordless account, set a default a role and send the user an email inviting them to signup/login (all via our own code)
  2. The user signs up/logs in (using google or whatever they want)
  3. A rule takes care of linking the accounts

I have the standard ‘Link Accounts with Same Email Address’ rule enabled, and then a subsequent rule that adds the users roles to the tokens e.g.

context.idToken[‘https://zzz.com/roles’] = (context.authorization || {}).roles;
context.accessToken[‘https://zzz.com/roles’] = (context.authorization || {}).roles;

This all works fine, except for when the user logs in for the very first time which ends up linking the accounts. There are no roles returned by (context.authorization || {}).roles, which means they can’t access my app. The very next time a user requests a token (e.g. refreshing the page) I get the roles as expected

So I assume (context.authorization || {}).roles is not returning roles for the primary account, but rather the newly linked secondary account. I note permissions are added correctly.

Does anyone know of a fix for this? It seems like a big bug.

I did spend a heap of time trying to retrieve roles in the role rule by firstly calling the user role endpoint directly and then by using the ManagementClient but both give me a insufficient scope (read:roles). I could try to setup an app with access to the roles claim and still use the ManagementClient but that seems like a huge workaround for what shouldn’t be an issue, and given the time invested I don’t want to waste more countless hours for something that still may not work.

Anyone have any ideas or a solution?

As an aside - why isn’t there a configuration option to add roles automatically like permissions? I imagine its a very common use case.

3

Hi @georgea,

Thanks for the feedback, we appreciate the insight!

It sounds like, if I understand you correctly, the roles you are accessing in the context.authorization object are those of the google (or whatever) account, and even though the account is linked in a previous rule, the context object is already set with the information of the single account. This would explain the roles being empty, like you already mentioned.

Can you manually set the default role based on a condition that it is a user’s first login using logins_count? Would that solve this issue, or is there something else going on here that prohibits that?

Let me know,
Dan

4

Hi Dan,

Thanks for your response. Yes that’s correct.

Just assigning a default role won’t work, as a users initial roles can vary, depending on what they were given by the admin.

I did try a auth0Client.getTokenSilently() call in the webapp after login to force an update of the token and therefore roles, but got a “consent required” error in this linking situation, which is also weird in itself, as I believe getTokenSilently() normally works outside of this situation.

At the moment, as a work around, I am forcing a refresh of the browser from within the webapp after login (just in this situation of where an account has been linked). Not ideal, but it does work, as the new token has roles returned. I would like a better solution though.

So my questions are:

  1. is there no way to reload the context object in a rule after linking?
  2. is there no way to look up a users roles in a rule, other than using ManagementClient and setting up a separate Auth0 app with the read: roles claim?
  3. why would getTokenSilently() be giving a “consent required” error?

Thanks for your help,
George.

5

This could be because you are developing on localhost, and might not be an issue once deployed.

Unfortunately, not that I know of.

This would probably be my recommendation, but only do this on the first login so the management client is not being hit every authentication cycle.

As I mentioned above, if you are developing on localhost this can happen. Check out this doc on how to get around it if thats the case.

https://auth0.com/docs/api-auth/user-consent#skip-consent-for-first-party-applications

Let me know how else I can help,
Dan

6

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