I am using password owner grant flow to authenticate user and able to fetch access_token successfully. In access_token, i also want roles, group too. For this, i installed Authorisation Extension and also published rule (enabled toggle buttons for storing roles,group & permission into access_token).
Questions
1). Tried passing scope as mentioned in docs i.e groups,roles but when recevied access_token got decrypted using JWT.io plugin , i found that groups,roles scope got ignored.
Passing roles and groups as scopes will only automatically add that information (if available at the user level) to the issued ID token (never to the access token) and only when the request is performed using a legacy authentication pipeline. If you’re performing a request that returns an access token valid for your own API then you’re not using the legacy pipeline.
The non-legacy pipeline strictly follows the OpenID Connect specification and does not include (not even for the ID token) the non-standard information about roles and groups as these are not standard claims defined by the spec.
If you want to include custom information in the issued tokens (either ID token or access token) then you should check the reference documentation on how to add custom claims.
Basically, create a rule that runs after the rule that the authorization extension created and set custom claims in the issued tokens based on the information at the user object (placed by the extension rule); for example, context.accessToken"https://myapp.example.com/roles"] = user.roles.
@jmangelo thanx for quick reply.
As per your comment, i am able to get group,roles and permission into access_token. With the same access_token, i am calling my web-api (set up correctly by following asp.net core web-api quickStart). But when debug, i am unable to find custom claims i.e. roles,group & permissions? As a result of which any method as below , wont be able to called.
[Authorize(Roles = “Admin”)]
@jmangelo :- can u plz provide me suggestions so that i can move further.
The suggestion made was for the problem of including that data in the issued token. The problem of using Authorize attribute to automatically check the included data is specific to how the access token is being processed in the receiving API. IIRC, in .NET you can configure it to treat a custom claim as the source of roles information. For example, for a ClaimsIdentity there’s a constructor that allows you to do it.