Extending Azure AD B2C with Custom Role Management and Token Handling in Microservices

Question

Extending Azure AD B2C with Custom Role Management and Token Handling in Microservices

ii42-8206 20

Hi,

I am currently developing a microservice-based application (controlling both, the front- and backend) with Azure AD B2C as a user authentication solution. My focus is on extending the capability to manage custom user roles and permissions within the microservice system, separate from the identity management provided by Azure AD B2C, since management of custom user roles is not supported.

I would appreciate your guidance on a few specific points:

Token Management: Would it be beneficial to include role information from the service that handles the role management in Azure AD B2C tokens (ID and/or Access Tokens) for quicker role-based access control in our application? And is it possible to add the roles of the specific user in custom claims not just to ID-Token during sign-in but also to the Access Token? My understanding is that customization options are primarily for the sign-in process and claims in ID Tokens, while Access Tokens mainly contain application scope and subject information, but can't get information from external sources, like the roles service. I am asking, since treating a ID-Token like a access token (if the roles where included) seems a bit odd to me.
Refresh Token Revocation: Is it possible to revoke refresh tokens in Azure AD B2C? The documentation seems to provide limited information about this but mentions something about sessions.

I am also evaluating whether Azure AD B2C's capabilities are sufficient for complex role-based access control (RBAC) and fine-grained permission management for complex custom business logic. Please correct me if my understanding is not aligned with the platform's functionalities.

It seems like the client id within the OIDC scope, like stated in the documentation, could be used for something like this.

Afaik this is not a part of the Open ID standard but rather a Microsoft custom extension on top? Am I correct in this assumption?

Thanks for your help!

JamesTran-MSFT 36,906 Reputation points Microsoft Employee Moderator

2023-12-13T19:31:08.83+00:00

@ii42-8206

I wanted to check in and see if you had any other questions or if you were able to resolve this issue?

If you have any other questions, please let me know. Thank you for your time and patience throughout this issue.

If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.
ii42-8206 20 Reputation points

2023-12-14T08:03:04.0433333+00:00

Hi @JamesTran-MSFT

Thanks for asking, I actually have two more questions:

Is it possible to split the custom claims between the different token types (user information only in the OpenID Connect token and for example roles of the user from a third service then only in an access token) or are custom claims always present in both tokens and this functionality cannot be implemented even with custom policies? Unfortunately, I have not found any information on this in the documentation of custom policies.

And how would this work in the authorization code flow, for example, since a token is not returned directly after the policy is called, but only a code, is it still possible to include your own claims from third-party sources in tokens?

Is it possible for a RESTful technical profile to authenticate itself against an application registration in AD B2C in the client credentials flow in order to then send a request to a third service with a bearer token? In other words, that the technical profile authenticates itself against its own tenant, so to speak? Client Certificate is recommended in the documentation, but an OAuth2.0 access token would be particularly suitable in this case.

1 answer

Your answer

JamesTran-MSFT 36,906 Reputation points Microsoft Employee Moderator

2023-12-13T19:31:08.83+00:00

@ii42-8206

I wanted to check in and see if you had any other questions or if you were able to resolve this issue?

If you have any other questions, please let me know. Thank you for your time and patience throughout this issue.

If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.
ii42-8206 20 Reputation points

2023-12-14T08:03:04.0433333+00:00

Hi @JamesTran-MSFT

Thanks for asking, I actually have two more questions:

Is it possible to split the custom claims between the different token types (user information only in the OpenID Connect token and for example roles of the user from a third service then only in an access token) or are custom claims always present in both tokens and this functionality cannot be implemented even with custom policies? Unfortunately, I have not found any information on this in the documentation of custom policies.

And how would this work in the authorization code flow, for example, since a token is not returned directly after the policy is called, but only a code, is it still possible to include your own claims from third-party sources in tokens?

Is it possible for a RESTful technical profile to authenticate itself against an application registration in AD B2C in the client credentials flow in order to then send a request to a third service with a bearer token? In other words, that the technical profile authenticates itself against its own tenant, so to speak? Client Certificate is recommended in the documentation, but an OAuth2.0 access token would be particularly suitable in this case.

Answer 1

Marilee Turscak-MSFT 37,206 Microsoft Employee Moderator

Hi ii42-8206,

You cannot use RBAC out-of-the-box with Azure AD B2C. The roles would need to be assigned within the B2C's AAD directory or hosted externally and retrieved via Graph API, or if you are using ROPC you would still have to make a call to the underlying AAD and only Microsoft accounts (and not social identities) would be supported. Azure AD B2C does not support out-of-box support for role claims for consumer accounts as it would not be feasible for the admin to assign the role to consumer identities.

You can use custom claims in to allow consumers to select the required role during the signup process which is returned in the token as well. https://learn.microsoft.com/en-us/aspnet/core/security/authentication/claims?view=aspnetcore-7.0

You could also leverage Custom Policies, which allow you to call a REST API during authentication. This can be used to pass the ObjectId of the user to your API and return the roles to Azure AD B2C. B2C can then issue the roles as a claim into the token.

https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-api-connector-token-enrichment?pivots=b2c-custom-policy

2.You can revoke refresh tokens by these methods:

Using Graph API. Notice that the method is called “invalidateAllRefreshTokens".
Via a custom policy
Via PowerShell

I'm not sure I fully understand your question about client ID, so feel free to clarify. But this parameter applies not only to Microsoft but is used by other identitiy providers too. For example, an id_token value received from Google would need match the value of the --oidc-client-id parameter.

Let me know if this helps at all and if you have further questions.

ii42-8206 20 Reputation points

2023-12-02T09:04:52.47+00:00
Thank you very much for your quick reply! It would be very kind if you could perhaps respond to the question regarding the client id in the Open ID Connect scope. I will try to explain my problem in more detail:

The question about the client ID was about the following sentence in the doc: "Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID"

This is listed under the OpenID connect scopes in the documentation for retrieving an access token. This possibility to retrieve an access token scoped for an application does not appear (to my knowledge) to be part of Open ID Connect standard, but extend it. I am now wondering if I can simply use this access-token for my own backend and only include the roles there (which I would include using a custom policy calling the REST-API of the roles service).

For clarification on what I exactly mean:

When I configure an application in the tenant there is an option to select the tokens to be issued by the authorization endpoint (Select the app > Authentication > Platform configurations), where I can select ID and Access Token. The UI of the Azure portal then states I should select both if the application has a single-page architecture (SPA) and does not use an authorization code flow, or if the application calls a web API via JavaScript. The latter is the case for me. I need an ID and access token during authorization code flow, that includes roles of users I get from the roles service REST API using the custom policy. The access token would then be used to call my own backend.

However, this behavior is not part of the OIDC standard as far as I know and it seems that this is a Microsoft custom extension on top of Open ID connect. Can this be used for something like my use case described, i.e. if you don't need a scope but simply an access token with custom claims for your own backend and an ID token for the frontend? I am a bit confused what access token actually means in this context.

Here is what I want in summary, using the authorization code flow:

AD B2C authenticates the User and calls my SERVICE_1 for custom claims (e.g. the users roles)

AD B2C returns an ID and Access token

My SPA uses that (kind of first party) access token to access my resource SERVICE_N

I hope that makes it a little clearer.

Share via

Extending Azure AD B2C with Custom Role Management and Token Handling in Microservices

1 answer

Your answer