I added the Authorization Extension into my tenant.
In [Authorization Extensions → Configure] I enabled groups/roles/permissions and published the rule. A new rule ‘auth0-authorization-extension’ is created automatically.
Inside this rule, I had to change the context.cliendId (I don’t remember the exact property) of the ‘policy’ API method by context.sso.current_clients[0].
The sso.current_clients contains two values in my case. If I use the first one, the permissions are correctly fetched but if I use the other one (and the one that was previously in the code) the permissions or roles fields aren’t filled.
The code of the auto-generated rule doesn’t work as-is for me. Did I missed some configuration?
Most configuration in the authorization extension is done in association with a particular client, in particular, when you create roles and permissions you do so for a specific client. This means that when the policy is retrieved for a given client it will do so taking in consideration if roles/permissions were created for the client in question.
Based on the information provided you seem to have more than one client application and for one it gives the expected information so can you review if this is not just a case of incorrect configuration of the extension. For example, you only have roles permissions for one client application. In addition, you should use context.clientId as that is associated with the client application performing the request; if you a different client application identifier then you return roles that are possibly not meant for the application performing the request.
If I have the role “admin” on a website using a mobile device; it doesn’t make any sense not to have it on the same website from a computer browser.
I have only one client: a website. But I can access this website from my mobile phone or from my computer. The client in both case should be identical and it isn’t.
You’re correct that there may be a mismatch in expectations in terms of what the extension expects and what OIDC/OAuth 2.0 recommend. The extension expects an association with a client application while the protocols may recommend different client identifiers for different platforms (web vs native).
In this particular situation and in order to avoid duplicating everything for more than one client you can indeed consider updating the rule to apply some normalization. For example, service A has client ID XyZ for web application and client ID wqX for a native application. You can choose to configure the extension against XyZ and then update the rule to have an hardcoded normalization, something like:
var cid = context.clientId;
if (cid === 'wqX') { cid = 'XyZ'; }
// call get policy with normalized ID
What’s important is that you’re doing this explicitly and treating wqX as an alias of XyZ for the purposes of the extension call; this is acceptable due to being explicit. What’s not recommended is to just pick the ID from another place in the context, for example, context.sso.current_clients[0]. In this case in your tests the context.sso.current_clients[0] happened to be what you want, but that is not a stable approach.
You misunderstood something: I don’t have any native client. Only the same website hosted on the same server by I access it using different browsers (Firefox on my computer and edge on my phone).
Yes, I did… can you capture an HTTP trace of the two attempts that go through Auth0 (redact passwords, session cookies and at least token signatures) and also the output of context.clientID from a rule in association with each attempt. I just accessed a test web application from both browser and got the same expected value in context.clientID.
Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.
Wanted to reach out to know if you still require further assistance?