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?
Related
I am using Azure B2C in my react SPA to sign in the user with external identity providers e.g. Google and Facebook. I have some .net core web API that needs to be called by signed-in users only. I have followed Azure documents for my scenario. As per the docs, I need to register another AD B2C application for web API security and my client app needs to acquire the token with the scope defined in the server-side AD app and pass that token while calling the web API.
Why can't I use the same access token received from azure AD B2C as part of the sign-in flow to pass it to my web API and validate it on the server side to secure the Web API? In that case, I don't need to create another server-side AD application for securing the API.
You can, but it’s simply against the protocol spec. Each client needs to be registered and have a unique client Id/AppId.
Plus if you do it with one App Registration, your logs would never differentiate access to your front end vs access to your api.
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).
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.
Entering the AWS management console, how does one build an SSO solution where authentication is done against Azure AD but authorization level is in AWS IAM?
Azure AD SAML claim will not include any security group data, since we don't want to overload SAML token with metadata. Same applies to Kerberos tickets. Hence using the Azure AD Graph API is out of question as well.
Basically the SAML assertion will only include data about authenticated user.
The AssumeRoleWithSAML API is role-driven, whereas we would need a SAML based solution that is user-driven (mapping incoming user data with IAM user). Any help is welcome.