You’re offline. This is a read only version of the page.
43
We want to have clients authenticate using their own AAD credentials, so they don't have to remember yet another password just to use our product.
I came across this article which seems to indicate it is indeed possible, while searching on this forum hints at the opposite.
So is it possible?
EDIT: To make this first post seem less vague, here is some more information:
Finally, I don't HAVE to use B2C nor Recommended user flows. I am only doing so because the documentations keep recommending to do that.
The single only business need we have, is that any user with a Microsoft school or work account should be able to register without entering any credentials, and with as few clicks as possible. So far any user we haven't invited to our B2C tenant beforehand will get an AADSTS50020 error upon using the user flow.
Yeah, one thing I missed from my re-write was emphasizing I am not an expert by any means. 😁
The understanding of "all users from @customer1.com" makes sense also. Either one sounds more like B2B than B2C.
For the "from the user flow window," I mean when you click the Run user flow button in my first post, it should pop out a blade on the right (same one you might have used to get the claims JSON) and at the bottom you should be able to copy the link or click the "Run user flow" button again and see the sign-in page just as you would from the Portal. It's basically just saying to cut out the Portal component, because the real issue for you is that B2C users need to be invited or pre-existing and you don't want that, I believe.
Unfortunately, mine are set up similarly through Application Claims:
I haven't tested it yet, but I have an inkling I might be able to get the claims in question if I remake the Identity Provider with 1.0 config rather than 2.0. I might return to that, but for now I would prefer to focus on the real issue at hand.
Speaking of, just for fun I want to give you the frustrating insight into what being me feels like right now:
All links have already been visited. I read them again, and Direct Federation does not really sounds like what I am looking for, I might be reading it wrong.
To me it reads as if we want to "invite" all users from @customer1.com, Direct Federation is the way to go. In reality, we would rather have literally ANY work or school account managed by Microsoft to be able to register on our portal without being invited first. And not using local accounts, because remembering passwords is not an option for our customers.
I am not sure what you mean by when it works directly from Azure B2C's User Flow window. As of now, if I invite a user to B2C, be that our test account from our own tenant or an external account not directly related to us, everything works perfectly! They don't even have to use the invite link in the email, the user simply needs to already exist in the B2C tenant or else they get the aforementioned error when trying to sign up/sign in. So as of now, everything is perfect, if only we didn't have to add/invite users to the B2C tenant first.
Your suggestion about taking this to the Azure community is probably a great idea. I will do that tomorrow.
Ahh, I had a whole reply also typed up that was running into issues. I'll try to re-summarize.
My manifest also shows null, but my Applications Claims has the names selected like so:
Also, this article seems to indicate that these were automatically included before Oauth 2.0, but need to be manually included now.
Lastly, thanks for getting us back on track!
Based on this article (which links to this other article describing what I think is your desire), it looks like you might not be able to leverage self-signup?
Direct federation: You can also set up direct federation with any external identity provider that supports the SAML or WS-Fed protocols. Direct federation allows external users to redeem invitations from you by signing in to your apps with their existing social or enterprise accounts.
Note
Direct federation identity providers can't be used in your self-service sign-up user flows.
Again, I believe your issue will be resolved when it works directly from Azure B2C's User Flow window, so it might be best to (in parallel) take this to the Azure community for help. Perhaps someone here can help still, but would probably be beneficial to get their feedback also. In all, I think perhaps Portal is just an unnecessary complication to the problem statement at this point.
No worries, I got the email for the reply. For the thread, here is @pmarnason's missing comment:
Yeah, I have seen/used that tutorial.
If you look in your B2C app's manifest, is your "optionalClaims" empty? On mine it is simply null.
At this point, I have been around the block quite a few times, there are some inconsistencies with the documentation and the actual implementation, as well as many linked articles that have been removed from docs.microsoft.com. I get the feeling that I have begun tackling this issue in a very unfortunate period where experts are recommending to use the new tools in favor of the ones being deprecated soon (B2C in favor of normal AD, "Recommended" user flows in favor of v1/v2, OAuth 2.0 in favor of 1.0), without these new tools having accurate documentation ready.
But we are losing sight of the real issue here! To be honest I can live without mapping other claims than email, and although this thread is not directly related to my issue, it seems to hint at it being impossible now, I don't know. It's very technical and my head is mushy after trying to solve this single issue for so many weeks.
So the main issue that remains is:
How can I configure B2C so that ANYONE is allowed to register through the user flow on my portal.
Yeah, I have seen/used that tutorial.
If you look in your B2C app's manifest, is your "optionalClaims" empty? On mine it is simply null.
At this point, I have been around the block quite a few times, there are some inconsistencies with the documentation and the actual implementation, as well as many linked articles that have been removed from docs.microsoft.com. I get the feeling that I have begun tackling this issue in a very unfortunate period where experts are recommending to use the new tools in favor of the ones being deprecated soon (B2C in favor of normal AD, "Recommended" user flows in favor of v1/v2, OAuth 2.0 in favor of 1.0), without these new tools having accurate user documentation ready.
But we are losing sight of the real issue here! To be honest I can live without mapping other claims than email, and although this thread is not directly related to my issue, it seems to hint at it being impossible now, I don't know. It's very technical and my head is mushy after trying to solve this single issue for so many weeks.
So the main issue that remains is:
How can I configure B2C so that ANYONE is allowed to register through the user flow on my portal.
Ahh, yes, my B2C is a few years old from one of my first POC implementations. My claims show as:
Share
Report
All responses (
Answers (
"claims_supported": [
"city",
"given_name",
"family_name",
"idp",
"emails",
"extension_MiddleName",
"sub",
"tfp",
"iss",
"iat",
"exp",
"aud",
"acr",
"nonce",
"auth_time"
]To be honest, I haven't worked with the external providers through B2C, so perhaps that's why your claims aren't working as I'd expect. However, looking at the documentation, it should still be working with the way you originally expected. I assume you've used this, then:
Tutorial: Add identity providers to your apps - Azure AD B2C | Microsoft Docs
Unfortunately, this might be more of an Azure B2C need than a Portal need, but I could still be wrong.
When I open my openID configuration through https://login.microsoftonline.com/{tenantID}/v2.0/.well-known/openid-configuration?appid={appID} I get the following JSON:
{
"token_endpoint":"https://login.microsoftonline.com/517bbe56-XXXX-XXXX-XXXX-b8d280dceeaf/oauth2/v2.0/token",
"token_endpoint_auth_methods_supported":[
"client_secret_post",
"private_key_jwt",
"client_secret_basic"
],
"jwks_uri":"https://login.microsoftonline.com/517bbe56-XXXX-XXXX-XXXX-b8d280dceeaf/discovery/v2.0/keys?appid=df5cdf23-XXXX-XXXX-XXXX-de80f6ea82b3",
"response_modes_supported":[
"query",
"fragment",
"form_post"
],
"subject_types_supported":[
"pairwise"
],
"id_token_signing_alg_values_supported":[
"RS256"
],
"response_types_supported":[
"code",
"id_token",
"code id_token",
"id_token token"
],
"scopes_supported":[
"openid",
"profile",
"email",
"offline_access"
],
"issuer":"https://login.microsoftonline.com/517bbe56-XXXX-XXXX-XXXX-b8d280dceeaf/v2.0",
"request_uri_parameter_supported":false,
"userinfo_endpoint":"https://graph.microsoft.com/oidc/userinfo",
"authorization_endpoint":"https://login.microsoftonline.com/517bbe56-XXXX-XXXX-XXXX-b8d280dceeaf/oauth2/v2.0/authorize",
"device_authorization_endpoint":"https://login.microsoftonline.com/517bbe56-XXXX-XXXX-XXXX-b8d280dceeaf/oauth2/v2.0/devicecode",
"http_logout_supported":true,
"frontchannel_logout_supported":true,
"end_session_endpoint":"https://login.microsoftonline.com/517bbe56-XXXX-XXXX-XXXX-b8d280dceeaf/oauth2/v2.0/logout",
"claims_supported":[
"sub",
"iss",
"cloud_instance_name",
"cloud_instance_host_name",
"cloud_graph_host_name",
"msgraph_host",
"aud",
"exp",
"iat",
"auth_time",
"acr",
"nonce",
"preferred_username",
"name",
"tid",
"ver",
"at_hash",
"c_hash",
"email"
],
"tenant_region_scope":"EU",
"cloud_instance_name":"microsoftonline.com",
"cloud_graph_host_name":"graph.windows.net",
"msgraph_host":"graph.microsoft.com",
"rbac_url":"https://pas.windows.net"
}
As you can see here, under claims_supported there is no given_name nor family_name. Email is there, explaining why claims mapping for the email attribute works.
Hopefully this can point us in the right direction, I don't really know where to look as of now.
EDIT: It is especially weird, since the "name" field needs the profile scope, so profile scope has definitely been activated.
#1
Lucas001
60
Super User 2025 Season 1
#2
Fubar
55
Super User 2025 Season 1
#3
surya narayanan
35
