-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add .WithKnownB2CAuthorityHost #911
Comments
It seems that the current strategy is the one that is not recommended. I propose we take this bug before GA. |
Alternative proposal:
In fact we can generalize this for all Authority types - just bear in mind that for AAD authorities have aliases. I think it's ok to force the user to specify the same authority in both PCA and AcquireToken*, but if you think differently, we can always perform InstanceDiscovery and take aliases into account. |
@bgavrilMS I don't think this will work for B2C because you can do different things in each acquire token call, without having to create a new client application. Another possibility would be something like this: application = PublicClientApplicationBuilder.Create(ClientID)
.WithB2CAuthorityHostInfo(authorityHost, tenantId)
.Build(); so they give the authorityHost like: Then in the AT builders, they would just pass in the policy: app.AcquireTokenXXX(scopes, mandatory-parameters)
.WithB2CPolicy(si_su_policy).
.ExecuteAsync(cancellationToken); We'd take the authority from the client application builder and append the policy. |
I like the high level API that you propose, we can even provide a bunch of constants for .WithB2CPolicy, or an enum, or both. So in the B2C case, if the developers still use: On my proposal, developers can use any policy they like, because the host part of the URI doesn't change. |
@bgavrilMS I think, currently, if a b2c developer uses |
I like you proposal a lot @jennyf19, and I've discussed something similar with @valnav who also liked it. The thing is that by explicating a .WithB2CPolicy, we can also take care of other aspects like get the account for the policy, and the prompt=none for some policies. this requires a bit more spec, but I'd really like to go there. |
@parakhj - thoughts on the above proposal? |
Can we call it IEF policy? I know it's silly, but B2C runs on top of "IEF (Identity Experience Framework)", so really it's an IEF policy. Now we can argue that most developers don't know what IEF is, which is a valid argument, but IEF policy is technically accurate than "B2C policy" |
@parakhj thanks for the insight. much appreciated. |
@parakhj do we expect IEF to be surfaced to customers in the future? I'm worried that B2C developers (who know they want to use B2C) don't discover easily that they need to use WithIEFPolicy? or would they? |
@valnav what are your thoughts on this? |
@markti thoughts on the above? |
B2C is more close to the scenario they are building today. Also, using IEF may confuse the developer between User Flows and Custom Policies. However, B2C as you say may not work as well - cant we stick with what we have in Microsoft Graph which is TrustFrameworkPolicy |
Closing as we've decided not to particularize B2C in public API |
Is your feature request related to a problem? Please describe.
Enable B2C developers to tell MSAL about their known authority hosts, and the corresponding OAuth2.0 metadata
Describe the solution you'd like
Add the possibility of adding to the ApplicationBaseBuilder the following method:
.WithKnownB2CAuthorityHost(string authorityHost, struct describing the metadata)
Describe alternatives you've considered
see App developer is protected by authority validation when using *.b2clogin.com
The text was updated successfully, but these errors were encountered: