Greetings,
I am trying to set the ‘role’ claim, for example: ‘role’ : ‘admin’ in the returned JWT. I’m adding it with a custom rule (is there another way?)
The problem is that, much to my surprise, the documentation clearly states that in spite of the specification CLEARLY ALLOWING it, Auth0 will REMOVE any claims without a namespace scoping.
So, toss the spec out the window and let’s go!!
(Do that once, get a reprimand, continue doing it, and I’ll kick you butt out to street. Follow the specs - teach that to all Jr. Programmers. Can’t do that, work somewhere else!)
OK, well, it is a standard namespace scoping, so I add:
And the stupid thing doesn’t recognize it as a standard role, so instead of returning ‘role’ in the JWT, it puts it in exactly like above, with the namespace. Ack! Phew! - Well, at least that is mostly expected.
So, HOW do I create ‘role’ in the JWT, or do I have to dump Auth0 completely? (modifying the standard OAuthService object in Angular to support the namespaced role isn’t really an option.)
or something similar in the idToken. As you note, Auth0 requires the use of a URL style collision resistant namespace. This is the OpenID Connect recommended practice. It is true that it is not required, but that is the way Auth0 works today. As far as I know there is no way to do precisely what you are trying to do.
I’m not sure what you mean by “the thing doesn’t recognize it as a standard role”. If you can provide some context that might help.
The namespace listed above (from Microsoft), is mapped to ‘role’ by ADFS, and is recognized by Angular’s OAuthService and mapped from the JWT (AuthToken) to the ‘role’ in the object. This allows you to read the roles in a standard way.
There is no way to create this from Auth0, as you specified. (Ideally, it seems that using your roles might map to it.)
I figured a way around it, that is a horrible hack - by modifying the code right after it reads in the JWT and maps into the OAuthService object, then I look at the JWT and see if I see an property named (Ack!) . [‘http://schemas.microsoft.com/ws/2008/06/identity/claims/role’] on the object (yeah, that ends up being the property name!) - thankfully, it can be created in Javascript, and can be accessed as well. I then take that and copy that object into the .roles property of the OAuthService. This allows the site to use either an ADFS implementation or Auth0, so it looks like I can hack my way past this limitation.
Still, I find it frustrating when a spec recommends a best practice, BUT clearly states that you CAN not do that - Specs are written this way for those situations (like this one), where you NEED to either override a standard value, or NEED to set a value without a namespace because you are using older code/a library code / or for whatever reason, non-changeable code. The guys who wrote the spec understood that. And Auth0 decided to add additional code specifically to not support that part of the spec.
Just saying, there are reasons people put things like this in the spec.
The concept of a ‘role’ is not part of the OAuth or OIDC specifications so there’s really nothing standard about this. These role entities are implementation specific. ADFS may recognize a ‘role’ entity (I’m not an ADFS expert), but the old Sun Directory Server recognized both ‘role’ and ‘group’ entities, while OpenDJ only recognizes ‘group’ entities. Auth0 itself has its own concept of a ‘role’ as part of the service’s new authorization framework.
Maybe Auth0 should allow the use of namespaces that are not collision resistant, which the specifications allow (but don’t require) and which would handle your use case, though I can understand their choosing to require collision resistant naming. I’d suggest leaving a feature request at Auth0: Secure access for everyone. But not just anyone..
At the moment your only option is to do as you suggest: in your application map the data from the JWT into the format you want to use. Note too (you probably know this but just mentioning for good measure) that you can use any URL you like (except Auth0 domains) for the namespace. No need to use schemas.microsoft.com. E.g., https://sso.foo.com/.
