I've set up a user flow in Azure AD B2C that uses the Phone/Email signup Identity provider.
The process works so far, but I want to get the phone number that is used to log in to store it in my application's user profile.
I plan to use the number for messaging at a later stage.
I've been looking around for hours and couldn't find any way to get it as a claim.
Is there any waty to retrieve the value, like getting it from the B2C AD with a separate request in the application?
If the phone number is collected for multi-factor authentication, You cannot read it using graph API or as a claim while using built-in user flows.
If you were to switch to custom policies, You can modify the policies to return it as a claim in your JWT token, write to it a custom attribute or use an API call to persist it somewhere else.
With custom policies, you still won't be able to read the phone number using Graph API as long as you are using the default claim. You would need to make some modifications to starter policies to save it to a custom attribute or mobile claim so that you can access it using graph API. You would also need to ensure that the extra claim is in sync with the default claim.
Note: If you use the phone signup sign in as mentioned here in the docs for user flows, you will be able to get the user's number with a graph call. It's explained in the same documentation.
Example
https://graph.microsoft.com/v1.0/users/{object_id}?$select=identities
"identities": [
{
"signInType": "phoneNumber",
"issuer": "contoso.onmicrosoft.com",
"issuerAssignedId": "+11231231234"
}
]
Related
I have a web application that uses Azure AD B2C, with custom policies, for security. When I look at the user accounts in the Azure AD B2C portal, I can see an editable Employee Id field. This field would be very handy to store an internal company employee Id, but I would like to include this field as an output claim in the auth token.
I've read the various documentation about the user profile attributes that are available through the portal, etc (https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-profile-attributes), but EmployeeId is not listed there.
Based on the documentation, I'm assuming EmployeeId is not available to custom policies, but I thought I would ask the question, anyway, to see if anyone has worked out a way to include the property as an output claim in the JWT auth token?
• Yes, you can surely include the ‘employeeId’ attribute claim in the Azure AD B2C custom policy as below to be included as an output claim in the authentication token. For that purpose, you will have to define the employee Id as a claim with the proper ‘DisplayName, DataType, UserHelpText, UserInputType’ wherein you will have to modify the ‘TrustFrameworkExtensions.xml’ as below: -
Then, add the claim to the user interface in the local account signup technical profile as below since you want the ‘employeeId’ attribute to be included as a field in the output claim under ‘LocalAccountSignupwithLogonEmail’: -
Once done, then use the ‘PersistedClaims’ to write data to the user profile and ‘OutputClaims’ to read data from the user profile within the respective Active Directory technical profiles as above. Then, include a claim in the token in the ‘SignuporSignin.xml’ file and that output claim will be added in the token after a successful user journey and then modify the technical profile element within the relying party section to add the ‘employeeId’ as an output claim as below: -
Once the above things are done, then you surely can upload the custom policy and test it through your web app for the ‘employeeID’ attribute.
For more information regarding this, kindly refer to the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-user-input?pivots=b2c-custom-policy
Custom policies Azure AD B2C issue with read the value Employee ID of user of Azure AD
To solve this, I ended up adding a REST API call, in the custom policy, that extracted EmployeeId via Graph API. Great suggestion by #juunas.
This works well, although it would be good if EmployeeId could be exposed as a claim without the REST call as I feel this adds a point of failure to the whole Sign Up/Sign In flow.
But it works.
I have an AzureAD application registration for my front end SPA. I am using Angular with Microsoft’s #azure/msal-angular v2 authentication library. My app registration has all the necessary redirect URIs and configured for proper OAuth2 OpenID Connect using authorization code flow with PKCE. My app is using the Microsoft Graph API with only the User.Read scope. I can authenticate just fine. If my app, however, is only available for one group of people, defined by an AD group and assigned to the Users and Groups section in Azure, what is the best way to validate the logged in user is authorized? I’ve tried enabling optional group claims for the access token, but those don’t come through for some reason. I then tried adding roles-I have an “admin” role, which is the only one I need. This role is assigned to the AD group I mentioned earlier. The roles claim does come back, and I can use that, but this seems silly when I should be able to just validate if the logged in user is in my AD group. The roles approach does have the nice feature of just assigning users different roles to validate authorization for development purposes, but not sure if there’s a better way.
At some point there will be an API I need to plug in. Would it be best to get the claims from that and use that for validation?
Is there a scope or setting I’m missing? Am I achieving this all wrong? Thank you to all who reply.
At this point, you have a SPA that calls a MS 1st party API, which is MS Graph.
Since you are acquiring an accessToken to MS Graph, this accessToken can not be changed - it is meant to be decoded and validated by MS Graph itself, so you will not be able to add any extra claim on that token since you do not control the resource.
Also, your client should treat the accessToken as an opaque string, you should never rely on any claim from the accessToken on the frontend.
You can read more about it here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
If you want to do some sort of authorization on the frontend, like deciding which routes your user will have access to, you need to rely on the idToken. For the idToken, you can enable the Groups claim and get a list of groups that the user is a member of.
If, as mentioned, later down the line you need to create a custom API and call it from your SPA, then, on that scenario, you can indeed add the Groups claim to the accessToken, because it will be a resource that you control, and then authorize the requests that hit your API based on that claim
MS has a sample that shows exactly how to use security groups for access control, using an Angular frontend with a .NET Core Web API. Give it a check here:
https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/blob/main/5-AccessControl/2-call-api-groups/README.md
Can someone provide a general approach to meeting these requirements? I've spent a bit of time researching these various topics and attempting to implement solutions and I'm surprised at how much work is involved. Hopefully I'm missing something.
How do I invite consumer users to a B2C tenant so that they can authenticate into our application using their social accounts (ex: Personal Microsoft or Google accounts)? The only baked in solution on the Azure Portal I've found uses B2C local accounts. Note that I do not want to use a publicly accessible Sign Up flow.
Presently I'm looking into a custom process that would work by inviting users to a 'local' b2c consumer account and then allowing the user to associate their social account with the local account.
Once users have authenticated (using MSAL v2 Auth Flow w/PKCE), I want to retrieve a list of permissions the user has for our application.
I'm looking into two options here:
(1) use the auth token to verify user against an internal API that, in turn, makes a call to the Microsoft Graph API to get the user's group memberships.
(2) Create a custom claim that serves the same purpose as user groups
Administrative users of our application need to be able to invite additional users to the application.
I've found some articles that point, again, to using custom policies.
Thank you very much!
EDIT #1 -
Looking into using B2C & Microsoft Graph API I came across some decent, and recent, MS Resources:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/microsoft-graph-operations
And this important-to-me statement -> Microsoft January 28th, 2021:
"Although the OAuth 2.0 client credentials grant flow is not currently directly supported by the Azure AD B2C authentication service, you can set up client credential flow using Azure AD and the Microsoft identity platform /token endpoint for an application in your Azure AD B2C tenant. An Azure AD B2C tenant shares some functionality with Azure AD enterprise tenants."
I'll update my post when I find a solution. Thanks again!
You need to use custom policies.
For first bullet point, see my sample:
https://github.com/azure-ad-b2c/samples/tree/master/policies/link-local-account-with-federated-account
You could do either option. For option 1, AAD B2C can call your api which can call graph api to fetch groups. Then embed the info into the token. For option 2, you could write a role value to an extension attribute and return it in the token.
To invite users, you could use the invite sample. Essentially make an app that calls an API to generate these invite links and send those to the users email. The user clicks the link which allows them to complete their sign up.
https://github.com/azure-ad-b2c/samples/tree/master/policies/invite
We created an application in Azure B2C to use the OIDC implicit Grant flow. We have configured the Userflow policy(SignIn and SignUp) to customize the homepage layout and to get the custom claims in response. We are using Azure B2C as External Identity Provider (IdP) in our application. When user clicks the Login Button in our application we are redirecting the user the Azure B2C for Authentication and we are able to get the Access Token in response. But we are facing constrain in Getting the User Profile through the UserInfo enpoint. We have tried out both the Graph API endpoint and Azure B2C OIDC userinfo enpoint but neither of them are compatible with the Userflow policy.
I believe the workaround suggested is applicable only if we need to grab some extra input from user (during sign-up) or input validation and then pass that claim to application. It will unnecessary require using "Identity Experience Framework" feature which is ideally required for custom login/signup journey and is not available under free license.
What I understand from you requirement is you need to pass built-in Azure AD attributes to application and which shall be doable by selecting extra claims from "User Flow" signup-SignIn policy. Is not there any alternative to make call to "userinfo" endpoint out of box ?? Any Microsoft expert here, please clarify.
As of now, Azure AD B2C does not support the UserInfo endpoint through User-flow policy.
Right now, it is being supported only through Custom Policies.
You can vote for this feature on Azure AD User Voice.
A workaround is that you could integrate a Rest API to retrieve the extra claims.
See reference here.
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).