Background
I have two applications registered in azure, one is a web-based client and the other is a web-based service. The setup is similar to the example found here: https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi
The user logs in to the client via azure b2c, and then the client queries against the service, authenticated via azure b2c, to obtain its data.
The Problem
The service is not receiving the expected claims in the bearer token.
Specifics
Azure B2C says that the claims you select for a given policy will be included in "a token", which I assumed would be the bearer token. Below is a screencapture of some of the claims I have selected.
However, on the service when I extract the claims from the bearer token, I get none of the promised claims. Instead, I get the claims shown below.
I am using UseOAuthBearerAuthentication identical to the example provided by microsoft on github (linked above).
Am I missing something?
How do I get the claims that b2c promises?
Application Claims are included in the id_token, not the access_token (aka bearer token).
This means that the Select application claims will allow your client application (native app or web app) to access these custom claims.
If you want to access custom claims from your back-end service, you'll need to call the Azure AD Graph using the client credentials flow and call the user endpoint like so:
https://graph.windows.net/<yourtenant.onmicrosoft.com>/users/<userId>
And retrieve the property with the following format:
extension_<b2c-extensions-app_appId>_<customAttributeName>
For example:
extension_e5bf5a2db0c9415cb62661a70d8f0a68_MyCustomAttribute
You can obtain the id of your B2C tenant's b2c-extensions-app via the Graph as well:
https://graph.windows.net/<yourtenant.onmicrosoft.com>/applications?$filter=displayName eq 'b2c-extensions-app'
See this post for more info:
Moving Azure AD B2C custom user attributes across new environments
Related
I have a front end SPA (single page application) and back end api.
Each event in the SPA (like button click) invokes the respective api endpoint, and displays the result in the SPA.
I want to implement Azure AD based authentication so that only my Azure Tenant users are able to use the SPA/api.
Is the following flow correct approach to implementing such a feature:
User opens the SPA
User clicks on login button which opens Microsoft login popup
User enters Microsoft credentials in the popup, and if credentials are correct then user gets the JWT token
For every subsequent api request, the JWT token is placed in the bearer header
The endpoint validates the JWT token using Azure public key and rejects the request if token is missing or validation fails.
Is this flow correct and what is such a flow called?
There are several implementation steps that needs to be performed before you will have the flow that you have described:
User flow needs to be configured (Azure AD) - e.g. selfsignup allowed?
Backend and frontend applications needs to be registered (Azure AD)
Permissions and scopes needs to be added (Azure AD)
Backend API needs to be configured (e.g. API management) in order to validate the JWT token
I highly recommend to configure one of the Azure sample implementations end2end to get and idea of all the needed tasks: https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-authentication-sample-spa-app
The steps you outlined are correct.
An OAuth 2.0 "flow" outlines the steps to acquire a token from an Identity Provider (IdP). Since you are using a SPA, there are some restrictions on which flows you can use. A SPA can't act as a "Confidential Client" which is required for some flows. (Basically - the Client Secret required for the other flows would be visible in the browser network trace, so it's not "confidential".) The "Implicit Flow" used to be recommended for SPAs but it's less secure, so now the "Authorization code flow (with PKCE)" is recommended. Steps 2 & 3 in the question above are when you are executing the flow to acquire a token.
The authentication flow doesn't really address how you save and send the token to the API (#4 in the question), but the Microsoft Authentication Library (MSAL) helps with that - More information here - https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-overview
In Azure AD, you'll want 2 App Registrations - one for your SPA and one for your API. The API App Registration will need to "Expose an API" which really means to define a scope. Your SPA App Registration will need to Add an "API Permission" to the scope you defined from your API App Registration. (It will show up in My APIs.) This relationship is how #5 in the question is enforced.
Many of the steps for setting up authentication in Azure AD and Azure B2C are similar but Azure AD is designed for authenticating users that are part of your organization. Azure B2C allows you to build a set of users that aren't members of a particular Azure AD organization.
We have a client-server application that targets enterprise use cases mostly. We want to test if Azure AD is a valid IDP for our application that now supports authorization code flow but may be developed to support for authorization code with PKCE.
Our requirement is that we need 'preferred_username' and 'groups' as claims in the jwt based access tokens. The client application is a desktop based app (Win & linux) that authenticates users using any IDP speaking authorization code flow.
For POC, I used a trial account from Azure ad with default set of users in azure ad. Created security groups in the Azure Ad portal and added users to those groups. I registered apps as desktop/mobile based platforms and with an arbitrary redirect url. Under Token configuration, I added 'preferred_username' in access token as optional claim and 'groups' as part of both ID and Access Tokens.
I have set following in the application manifest:
"accessTokenAcceptedVersion": 2,
But these claims are never listed in the access tokens but only appear in ID token.
Is it possible to get these claims in access tokens, so the resultant access tokens can be used by our application?
Tried: Authorization code flow with PKCE for desktop/mobile app.
Expected claims preferred_username and groups in jwt Access token.
TLDR; Following below article, I am expecting an Access Token for my server:
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-your-web-api
In my understanding:
Client App ---> Client App on Azure (with scope perms to Web Api)
Server App ---> Web API App on Azure (exposing scope)
CLient App permissions
Also, I think I am dealing with 2 issues here:
Get Custom Claims in Access Token with Authorization code (or Auth code + PKCE)
Access Token should be meant for my application ( and not MS Graph)
When creating a App registration, you have to add
groupMembershipClaims": "SecurityGroup",
To your manifest to access the security groups
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims
If you creating a enterprise application you can add Attributes & Claims within the single sign on settings.
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
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).
I have an application that authenticates users agains Azure AD using OAuth and I want to provide the ability to setup certain information associated to each user by his admin in Azure AD, so I can read it as part of the authentication process. I would also like to be able to use the claims functionality provided by Azure ActiveDirectory so the admin can define custom mappings between user attributes in his AD and what I am going to read, as explained here.
Apparently those claims can only be read from a SAML token that would be the result of a SAML authentication, but since I am already authenticating using OAuth I would like to avoid having to do that. My question therefore is: can those SAML tokens or the information contained in them be obtained somehow either as part of the OAuth authentication process or afterwards?
When you say "provided by ActiveDirectory" you mean Azure AD not on-premises AD?
There is no way currently to add claims to the token in Azure AD. They are "canned".
That link you refer to is for SaaS application in Azure.
The way to get information out of Azure AD is via the Graph API.