I have a question regarding keycloak and Azure Ad b2c. Both offres authentication with different identity providers. Main difference I can see is in authorization. With Keycloak I can easily manage claims and roles of users via admin portal. In Azure B2c it looks very hard (setting custom policies) maintaining all the data via custom created app. Am I missing something? Relying app is strongly cloud native (Azure of course) and thats why I'm thinking about azure b2c. Relying app will strongly use roles and claims also.
What do you think about these two identity solutions (pros and cons).
What is the easiest way to manage implemented (by custom policies) user claims and roles in azure b2c? (do I have to write separate management app by myself or there is easiesy solution?)
Edit: first conclusion is that right nów azure requires separate app for connecting to graphapi (via rest or using sdk). Keycloak has it built in. Any pros of using b2c in this case (for c# dev)?
You don't have to use custom policies to use custom claims. Below an example :
On your B2C tenant, go to Azure AD B2C > Manage > User attributes and create a custom attribute; here a client ID attribute :
Then Azure AD B2C > Policies > User flows and create a flow, for example "Sign In" :
Use the recommended flow :
During the flow's creation, at the last steps, you can specific what claim will be included in the returned jwt token on Sign in; select our custom attribute Client ID :
Then when I login into my application using a B2C account, I have the below JWT token returned :
JWT token's payload, base64 decoded :
{
"iss": "https://mytenant.b2clogin.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0/",
"exp": 1664181788,
"nbf": 1664178188,
"aud": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"oid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"sub": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"extension_ClientID": 1,
"name": "myUserName",
"emails": [
"user#email.com"
],
"tfp": "B2C_1_SI",
"nonce": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"scp": "user_impersonation",
"azp": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"ver": "1.0",
"iat": 1664178188
}
I have set the "extension_ClientID": 1 using the msGraph API but this could also be done using a SignUp flow.
Related
I have a Node.js/Express application that uses Azure AD B2C for authentication.
Currently, two types of users can login:
Local accounts - EXTERNAL users in the Azure AD B2C tenant
Social accounts - INTERNAL users from a single Azure AD tenant
Desired Behaviour
I want to display different frontend user interface elements based on the type of user that has logged in.
Local accounts will be able to call endpoints relevant to EXTERNAL users
Social accounts will be able to call endpoints relevant to INTERNAL users
What is the recommended way to differentiate between who logged in?
I can see that the authToken object that is returned from msal-node's acquireTokenByCode() method is different depending on which type of user logged in.
Should I use a property from the authToken object to differentiate between user types?
If so, which property is the best one to use?
And, so that I can perform relevant UI actions accordingly, is it acceptable to store this value as a cookie in the browser (eg 'user_type': 'EXTERNAL' or 'user_type': 'INTERNAL') using something like js-cookie?
Below is a redacted version of the authToken object that is returned after login.
All values are the same for different users types, unless otherwise specified.
Notably, these two properties are only present after a 'social account' login:
idp_access_token
idp
{
"authority": "https://<my-azure-ad-b2c-tenant>.b2clogin.com/<my-azure-ad-b2c-tenant>.onmicrosoft.com/b2c_1_signin1/",
"uniqueId": "*******", // <-- different for each user, this is the object id of the user as represented in the Azure AD B2C tenant
"tenantId": "",
"scopes":
[
"https://<my-azure-ad-b2c-tenant>.onmicrosoft.com/my-web-app-api/tasks.write", // <-- these are the api permissions granted to my web app
"https://<my-azure-ad-b2c-tenant>.onmicrosoft.com/my-web-app-api/tasks.read" // <-- these are the api permissions granted to my web app
],
"account":
{
"homeAccountId": "***uniqueId***-b2c_1_signin1.<the-directory-id-of-my-azure-ad-b2c-tenant>", // unique id is different for each user
"environment": "<my-azure-ad-b2c-tenant>.b2clogin.com",
"tenantId": "",
"username": "<user-email-address>", // different for each user
"localAccountId": "***uniqueId***", // different for each user
"idTokenClaims":
{
"exp": 1673069519,
"nbf": 1673065919,
"ver": "1.0",
"iss": "https://<my-azure-ad-b2c-tenant>.b2clogin.com/<the-directory-id-of-my-azure-ad-b2c-tenant>/v2.0/",
"sub": "***uniqueId***", // different for each user
"aud": "<the-application/client id of my web app>",
"iat": 1673065919,
"auth_time": 1673065918,
"idp_access_token": "********", // <-- this property is ONLY present in the authToken returned from the SOCIAL login
"idp": "https://login.microsoftonline.com/<the-directory-id-of-my-azure-ad-tenant>/v2.0", // <-- this property is ONLY present in the authToken returned from the SOCIAL login
"emails":
[
"<user-email-address>" // different for each user
],
"tfp": "B2C_1_signin1",
"at_hash": "*******" // different for each user
}
},
"idToken": "*******", // different for each user
"idTokenClaims":
{
"exp": 1673069519,
"nbf": 1673065919,
"ver": "1.0",
"iss": "https://<my-azure-ad-b2c-tenant>.b2clogin.com/<the-directory-id-of-my-azure-ad-b2c-tenant>/v2.0/",
"sub": "***uniqueId***", // different for each user
"aud": "<the-application/client id of my web app>",
"iat": 1673065919,
"auth_time": 1673065918,
"idp_access_token": "********", // <-- this property is ONLY present in the authToken returned from the SOCIAL login
"idp": "https://login.microsoftonline.com/<the-directory-id-of-my-azure-ad-tenant>/v2.0", // <-- this property is ONLY present in the authToken returned from the SOCIAL login
"emails":
[
"<user-email-address>" // different for each user
],
"tfp": "B2C_1_signin1", // different for each user
"at_hash": "*******"
},
"accessToken": "*******", // different for each user
"fromCache": false,
"expiresOn": "2023-01-07T05:31:57.000Z",
"correlationId": "*******", // different for each user
"requestId": "",
"extExpiresOn": "2023-01-07T05:31:57.000Z",
"familyId": "",
"tokenType": "Bearer",
"state": "",
"cloudGraphHostName": "",
"msGraphHost": "",
"fromNativeBroker": false
}
For Reference
For reference, below are the steps I took to:
Enable login from a single Azure AD tenant
Enable Azure AD users to be able to call Graph API in their own tenant
I added a single Azure AD tenant as an Identity Provider by going to:
Azure Portal > Azure AD B2C Tenant > Azure AD B2C > Identity Providers > + New OpenID Connect provider > [ fill in required fields and click 'Save' ]
Detailed steps on adding an Azure AD tenant as an identity provider can be found here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant?pivots=b2c-user-flow#configure-azure-ad-as-an-identity-provider
In the Scope field, I added the scopes that I wanted the Azure AD users to be able to use in their own tenant, i.e:
openid profile User.ReadWrite.All Directory.ReadWrite.All Team.ReadBasic.All TeamSettings.ReadWrite.All
Then I went to the relevant 'user flow' at:
Azure Portal > Azure AD B2C Tenant > Azure AD B2C > User flows > B2C_1_signin1 > Identity providers > [ check the recently added OpenID connect provider ] > [ click 'Save' ]
In order for Azure AD users to be able to make Graph API calls to their own tenant, I did the following to make sure that an idp_token was returned when they logged in - I believe this is essentially an 'access token' for their tenant:
Azure Portal > Azure AD B2C Tenant > Azure AD B2C > User flows > B2C_1_signin1 > Application claims > [ select 'Identity Provider Access Token' ] > [ click 'Save' ]
The idp claim is the one that you are looking for since it will be set of all external providers of the Azure AD B2C tenant.
Note that the idp_access_token claim is present when pass through is enabled but is only supported for OAuth 2.0 providers, so it may be blank for some.
I am configuring an OIDC-based SSO flow in Azure AD B2C using custom policy to allow users to login to downstream applications with their federated identity provider's (IdP) credentials. Custom policy is used to allow some complex business logic to be run prior to providing the token to the downstream applications.
The flow is correctly redirecting users to the external IdP for login and ultimately back to my downstream applications with associated claims. However, there is a custom claim that is only available in the access token received by B2C from the external IdP (not the ID token), and I can't figure out how to retrieve this claim from the access token to be used in the B2C user journey and ultimately provided with all the other claims to the downstream applications.
I can see that B2C does receive both the ID and access tokens by reviewing Application Insights logs (sample output):
"TESTtechnicalprofile": {
"ContentType": "Jwt",
"Created": "2022-10-15T07:37:45.8678974Z",
"Key": "TESTtechnicalprofile",
"Persistent": true,
"Value": "eyJhb..."
},
"TESTtechnicalprofileaccess_token": {
"ContentType": "Unspecified",
"Created": "2022-10-15T07:37:45.8678974Z",
"Key": "TESTtechnicalprofileaccess_token",
"Persistent": false,
"Value": "eyJhb..."
},
And general format of the payloads of the tokens is as follows:
ID Token
{
"<name of custom claim I can retrieve>": "custom claim value",
"iss": ...,
...
}
Access Token
{
"<name of custom claim I cannot retrieve>": "custom claim value",
"iss": ...,
...
}
I can successfully retrieve claims from the ID token by mapping from the partner claim type:
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="<name of claim containing email in ID token>" />
However this same method doesn't work for claims in the access token. If I reference the name of the custom claim in the access token in PartnerClaimType then B2C omits the claim (presumably because it fails to retrieve it).
I've tried retrieving the access token itself as a claim using the method described here and that works (token in claim matches token seen in Application Insights logs), however I'm not sure if it's possible to decode this token in B2C policy and subsequently pull claims from it (or even if one would want to do that).
While I could let the downstream applications retrieve what they need from the access token, I have business logic in my user journey that needs this claim prior to providing the final token to the applications.
Following up here for anyone else trying to do the same, according to Microsoft Support it isn't possible to extract a claim from an access token in B2C policy. I ended up crafting a workaround involving calling an external REST API from B2C to retrieve the needed info for the user journey.
Overview
We have an Azure AD secured API living in Azure as a web app. We need to be able to:
Trigger this API via user interaction from a client application (this part works).
Trigger this API programmatically from a scheduled job that will simply get a token & hit this API (this part does not work due to authentication issues).
Problem
The issue is that when we request a token from Azure AD, scope is not being set in our token claims resulting in the API rejecting the token.
This is the request we are making:
This request returns an access token with the following claims:
{
"aud": "<our api client id>",
"iss": "https://login.microsoftonline.com/<tenantId>/v2.0",
"iat": 1644421512,
"nbf": 1644421512,
"exp": 1644425412,
"aio": "<value>",
"azp": "<scheduled job client id>",
"azpacr": "1",
"oid": "<guid>",
"rh": "<value>",
"sub": "<guid>",
"tid": "<guid>",
"uti": "<value>",
"ver": "2.0"
}
As you can see scp (scope) is not included in the token claims even though we include it in the request.
If we use this token to make a request to our API we get the following error:
System.UnauthorizedAccessException: IDW10201: Neither scope or roles claim was found in the bearer token.
Any help on how we can get an access token from Azure AD with the proper scope/permissions to call our API, would be greatly appreciated.
Note
The Azure AD App Registration for our scheduled job that will request a token and then hit our API, does have the Delegated API Permission access_as_user which you can see I am including in the token request's scope.
The above is expected as using client credentials you can't get the delegated permissions i.e. the access_as_user permission and also the scope in client credentials should be used as api://<APP_ID>/.default . So , If you want delegated permissions then you will have to use implicit grant flow instead of client credentials.
For testing , I created two app registrations , One on which API is exposed (Postman) and other which is to be used for authentication (Powershelltest) and then , I have tested the same in 2 different scenarios like one for client credentials and another for implicit grant :
Main APP whose API has been exposed :
App used for authentication:
Scenario 1 Using Client Credential flow :
Scenario 2 using Implicit Grant flow :
I have an Angular Application which is authenticated using AAD B2C. This talks to a .Net Core API using an access token.
My problem is that I am not receiving a User Principal Name (upn) in my access token.
I have been adding additional "Application claims" like "Given name" and "Surname" and these appear in my access token just fine! Therefore, I believe that my scopes (openid, profile, email) are set correctly and that this in theory is working.
I believe since I am using version 1.0 of the token, that I do not need to configure an any additional claims in my application manifest. My user is a standard AD user not a guest.
The following document states that the upn claim should be included in the v1.0 tokens:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims
What am I doing wrong?!
Decoded Access Token:
{
"iss": "https://(my-tenant-name).b2clogin.com/(guid)/v2.0/",
"exp": (number),
"nbf": (number),
"aud": "(guid)",
"oid": "(guid)",
"sub": "(guid)",
"name": "My Name",
"given_name": "Given name",
"family_name": "Surname",
"country": "Norge",
"tfp": "B2C_1_signupsignin2",
"nonce": "(guid)",
"scp": "basic",
"azp": "(guid)",
"ver": "1.0",
"iat": (number)
}
UPN is not returned in AAD B2C tokens because it is an irrelevant random string that is set.
Rather AAD B2Cs unique name is stored in signInNames attribute, and returned in your token as email or username.
The doc you linked is for AAD, and irrelevant to AAD B2C. These are two seperate token issuer services. Select in your User Flow Application Claims to return “email addresses”.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-flow-overview#email-address-storage
At this time, apps that support both personal accounts and Azure AD (registered through the app registration portal) cannot use optional claims. However, apps registered for just Azure AD using the v2.0 endpoint can get the optional claims they requested in the manifest.
To achieve UPN Claim in the token, use B2C Custom Policy.
Refer this link for the starter pack: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
Add below claim to the TechnicalProfile AAD-UserReadUsingObjectId and in the Relying Party Policy (Eg: SignUpOrSignin.xml):
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
As per the code you have provided we observed you are using v2 endpoint( "iss": "https://(my-tenant-name).b2clogin.com/(guid)/v2.0/")
As per the document if you see iss:If the token was issued by the v2.0 endpoint, the URI will end in /v2.0.
In the V2 endpoint you need to make a request explicitly for UPN claim.
In v1.0 endpoint they are returned by default but v2.0 made smaller tokens so they made it optional.
Please go through the following links for more understanding. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims How to add optional claims in application manifest https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-app-manifest
I created an Angular application with Implicit Grant Flow for authentication and a Web Api in .Net Core 3.1 following this tutorial: https://github.com/Azure-Samples/ms-identity-javascript-angular-spa-aspnetcore-webapi
The problem is: I need to return the roles and/or groups of the logged User within the Bearer Token to authorize my API, but I'm not being able to do so.
I added the roles to the App Registrations Manifest here, added the claim 'groups' in the Token Configuration menu and set the "User assignment required?" as yes in my Enterprise App Configuration.
Even with all these configurations, I'm not able to return the roles/groups claims in the bearer token.
Example of the token the authentication returns:
{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "AAAAAAAAAAAAAAAAAAAAABTOBMzzWB5LS36oSmQMgyc",
"aud": "ecb5e87f-6f34-4f05-8e8d-8d6149178926",
"exp": 1597173984,
"iat": 1597170084,
"nbf": 1597170084,
"name": "name",
"preferred_username": "email#outlook.com",
"oid": "00000000-0000-0000-fa54-d112egdce65a",
"tid": "9188040d-6c67-4c5b-b112-36a304b643ad",
"azp": "edeb4b7d-9cac-4f3b-a21d-ead77993689e",
"scp": "access_as_user",
"azpacr": "0",
"aio": "DYNhHjG*PSY1ceuC11yaLYcLta8zh49iA!l2UCbCsH9QlaUkEHVQ4paQFRmb!qv7J6yTbAQItGWDgCW9UgUipz4Xnma*DOkFFDNIZ5lkffThD*ie91XMzZIoPhUPwNHOt5dLrw3VASE2WCvJfvDFOQk$"
}
Am I doing something wrong? Is there any other way to authorize the logged user in a SPA Application, return the token with the roles and groups and send it to the Web Api?
You should add the App Role into the manifest of the service app (TodoListAPI) rather than the client app (TodoListSPA).
Don't forget the assign the App Role to the users.
This should be able to fix your issue.
Hi You need go to azure ad -> app registrations -> your app -> taken configuration -> Add Groups Claim -> then select Security groups checkbox. Save. Then log out log in again and should be in taken under groups.