Thank you for the huge improvements that have been made in the latest versions of your OIDC marketplace module. At Enexis we have recently implemented version 3.1.0.
We found that in OIDC.webCallBack you have made the assumption that the application roles are always part of the Access Token. However, in our case the user roles are part of the Identity token (and not the Access token). As a result we had to modify your standard OIDC.webCallBack microflow. In the step where the Roles are parsed from the token we have to pass the Identity token instead of the Access Token.
We use EntraID as IDP. As it is quite common that EntraID passes the application roles immediately in the ID-token, it would be great if you can add that option to your OIDC module. For example by making it configurable/selectable whether the roles are passed in the Identity or in the Access Token.
With such option all customers that have EntraID can use your marketplace module OOTB, without any custom changes.
We have implemented version 4.2.0 and are using Entra ID.
In Entra ID we maintain a specific set of roles per application. This allows us to determine which user roles are assigned to a user by adding them to a particular group.
The issue Jaco raised—where the roles claim appears only in the ID token and not in the access token—seems to still exist. Is it possible to make both the access token and the ID token available to the CustomATP microflow?
By doing so, we would only need a custom version of the Default_Azure_TokenProcessing_CustomATP flow, rather than modifying the webCallback microflow or duplicating the web service and microflows used for the callback.
Perhaps you could also add a constant that lets us choose which token we want to use in the CustomATP microflow. That way we wouldn’t need to implement a custom microflow.
Thanks for the positive feedbcak!
The challenge with OAuth/OIDC is that these standards allow for a lot of flexibility on the contents of Tokens.
We're trying to at least support the standard best practices.
Particularly authorization information should preferably be in Access Tokens.
Access Tokens are designed to be used for API consumption (as bearer token) / invoke Resource Server.
The guiding principle is "scope value = userrole".
Nevertheless we want to be flexible, particularly for customers using EntraID, so
I'll take your suggestion into consideration. I'm curious to learn why the AT-approach wouldn't work with Entra ID. Maybe you're aiming for a situation with static set of roles in EntraID and you don't want new scopes to be introduced for every app?