What are ways to include custom claims (user subscriptions or roles list as example) in a token before issuing it in Azure AD B2C, provided that claims are stored somewhere on own server (not available in B2C)?
Goal to have claims in the token to avoid additional round trip to the storage on every request.
Investigation on the topic brought me to following ways:
Add custom attribute via Graph API, configure to include in JWT. Attribute values should be kept in sync with our datastorage.
Custom Sign-In Policy like in this article https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom but if I got it right, additional Step 6 is a user journey to publicly available API in non restricted way (request not secured by secret, might be used to get user claims by presented UserId)?
IdentityServer4 Federation gateway http://docs.identityserver.io/en/release/topics/federation_gateway.html that will allow to add any claims before issuing.
The first two mechanisms you outlined are the most common and recommended ways to include custom claims in an Azure AD B2C issued token:
Add a custom attribute and include it in the JWT. You can enable the custom attribute via the B2C UI or via the Graph API. You'd need to build your own mechanism to keep the value of this attribute in B2C in sync with your external source via the Graph API.
You can use a custom policy to add a step in your authentication flow to call a Rest API to obtain the claim and include it in the token. This call to the Rest API will be performed by the Azure AD B2C service and NOT the user's browser, so it'll be a service-to-service call (versus a client-to-service call), keeping any secrets you use for authentication with your Rest API safe (such as a Azure function code).
Related
I am using an Azure ADB2C tenant to sign-up/in users with custom policies and rest api claims exchanges. This works fine.
Now I would like to start a service (daemon) that runs in a cloud environment for each user that signs-up with my service. This background service will access resources on other servers. Accessing these resources require a token and the service should only have access to the resources that the user has (i.e.: the access token used by the background service should also include the custom REST API claims). For the common users, this is taken care of by my REST API claims server, which enriches the token in such a way that it gives users' access only to the allowed resources.
I have found this page describing how to get access without a user. But this page assumes that the background service is a single instance that has access to all users' data that it needs. My background service is a 1-to-1 mapping to the signed up user.
Ideally this is how I see it working:
A new user signs up.
My REST API claims exchange gets called for this user.
Call Azure ADB2C to create a token for the background service. (Token should also contain my custom claims)
Start a new instance of the background service using the token created at step 3.
Return the custom claims for the new user.
This will happen for every new user, so every user in my system will have a corresponding background service running in the cloud.
Is this possible with Azure ADB2C? If yes, how?
The link you provide to get access without a user is only suitable for calling ms graph api and not for calling custom api.
If you are calling ms graph api, then you can indeed use the daemon-based client credential flow to obtain an access token (that is, without user involvement). This flow is usually used in Azure AD, but if it is used to call ms graph api, then it is also applicable to Azure AD B2C.
But if you are calling a custom api, then you must use a user login flow. Azure AD B2C obtains tokens in a different way from Azure AD. To use Azure AD B2C, you must first create a policy to enable users to sign up and sign in to your application.
For multiple applications. we are using AAD B2C for our authentication system.
We have opted for custom policies. One of the reasons for this is that we want to allow different user groups to access different applications, in the following way:
superusers can access all Applications, including our CMS
product admins can access the customer facing CMS and the end product
product users can access the end product
For this, we have the policies:
B2C_1A_xxx_cms
B2C_1a_xxx_product
B2C_1A_xxx_customercms
In all policies, we do an API call to an internal authentication API, which validates the user's group memberships throught MS Graph API.
The problem is that these policies seem to be able to be used interchangibly:
https://{tenant}.b2clogin.com/{tenant}/b2c_1a_xxx_cms/oauth2/v2.0/authorize?response_type=id_token&scope={scope}%20openid%20profile&client_id={client_id}&redirect_uri={redirect_uri}&nonce={nonce}&client_info=1&x-client-SKU=MSAL.JS&x-client-Ver=1.4.4&client-request-id={client-request-id}&response_mode=fragment
In the above url, users can access the CMS by replacing b2c_1a_xxx_cms with b2c_1a_xxx_product, thus bypassing the group-based validation in place for the specific application.
The original implementation of our policies are based on this tutorial:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
How can we configure these policies in such a way that changing the URL and trying to log in is impossible?
Based on your requirement, I think you need a the application assignment to users feature.
But it is only available in Azure AD rather than Azure B2C.
So I suggest that you use custom attribute to control the access of the user for different applications.
“ we do an API call to an internal authentication API, which validates the user's group memberships throught MS Graph API. ”
When User A calls Policy B, this API should return back a claim into the journey that prevents it from issuing a JWT. That can be achieved by creating a “block page” using a self asserted technical profile. Call this from the orchestration step using this claim from the API to trigger it with a precondition.
We are developing a web application using Azure AD B2C as the identity provider. For that we use custom policies and during the authentication flow, AAD B2C communicate with a REST API to get extended user claims.
Also, we want to pass value to the REST API from the client application. We were planning to use state parameter of the Authorization Code Flow, to do that.
My question is how can we access that state parameter value via custom policies and so that we can pass that to the REST API as an InputClaim?
I'm evaluating Azure B2C but can't work out whether it will be fit for the following scenario:
We have a single UI and and a single Web API. The API has two scopes defined: read and write.
The UI has two types of users: standard and admin. When a user logs in and gets an access token they both get a read scope but only an admin user should get write.
From what I've read Azure B2C doesn't support group based application, but is it possible to hook in to the token generation (e.g. a Function) and add a custom scope programmatically? I was thinking that if I can call a Function then this could check something to see if they should have the write scope added.
Thanks
Scope o scp claims cannot be manipulated in B2C. However you can use custom policies and add (in a base policy) and output (in your relying party policy) a roles claim type so what your webapi do role base authorization (.NET core sample here). You can fill the roles values from the output claims provided by any technical profile which in turn relay on any configured Idp, AAD or even REST apis).
I got the workaround to work to add claims to the token using a custom REST API, however I realized this is the Id token and not the Access token. I need the custom claims to be the Access token to use for authorization in the service.
I haven't inspected the Access token yet but are these claims also inserted into the Access token?
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw
Yes, custom claims come back when requesting access tokens. The only difference in the list of claims is the scp claim. The scp claim is only returned on access tokens.
Unfortunately, the Claims in ID and access tokens documentation doesn't discuss this.
You can quickly verify this via the Run Now feature in the Azure Portal. See this SO answer.
Sample access token w/ a custom claim
I am using custom claims in my Azure Active Directory B2C tenant where I registered two applications (UI and API). The UI passes the access_token to the API and I am able to retrieve the custom claims there. I guess this should be also true for custom claims using a custom REST API.
If not, It must be possible to setup:
... The return claims can be stored in the user's Azure AD account,
evaluated in the next Orchestration Steps, or included in the access
token
If your question is "Can I get the user's access token from the federating IdP such as Azure AD, facebook etc"? The answer currently is no. You can vote for this feature here.
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/15334347-return-social-idp-s-native-access-tokens-back-to-t