AddMicrosoftAccount is deprecated.

[geno-github]

Please replace this method with supported method like AddOpenIdConnect. Thanks.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a4c264c0-0c5c-298e-bb45-9b4891c8d162
• Version Independent ID: ce69b990-0b4c-abda-cd2d-68f85cd8031e
• Content: Microsoft Account external login setup with ASP.NET Core
• Content Source: aspnetcore/security/authentication/social/microsoft-logins.md
• Product: aspnet-core
• Technology: aspnetcore-security
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

@geno-github see this GitHub comment

Update: For 6.0 we should obsolete AddMicrosoftAccount and AddGoogle and rewrite the docs to use AddOpenIdConnect.

Sor for now, keep using AddMicrosoftAccount until we add AddMicrosoftAccountOidc

[Tratcher]

Reviving this. While we don't intend to deprecate AddMicrosoftAccount or add AddMicrosoftAccountOidc in 6.0, we still want to transition the docs to show using AddOpenIdConnect (or Identity.Web) instead. @blowdart

The same goes for AddGoogle.

[Tratcher]

@jennyf19 for guidance on moving to Identity.Web.

[Rick-Anderson]

@jennyf19 if you can outline the steps we'll get this published.

[jennyf19]

yes @Rick-Anderson will do. thanks.

[jennyf19]

msa.md

@Rick-Anderson @Tratcher Here is an md file above with suggestions. Just a note, that most customers use the 3rd or 4th option in the screen shot below from the portal. The difference in code (which i mention in a comment in the md file) is in appsettings.json, either using /common (or 3rd option) or /consumers (4th option). if using /consumers, the UI that is rendered from AAD is ONLY for MSA.

Login w//common UI:

This is the error, if I try to use an MSA only app with a non-MSA account because I don't have /consumers in the appsetting.json

Login w//consumers UI:

[Tratcher]

Thanks @jennyf19.

There are a few details to work out:

• These social providers aren't usually set as the default scheme, Identity is. We'll want the first sample to show working with Identity and a secondary sample for stand-alone.
  • It looks like that will require setting the cookieScheme to null?
  • How to set the display name so this still shows up as Microsoft Account on Identity's external providers page?
• What does the migration story look like for someone using AddMicrosoftAccount today?
  • Are the unique user ids the same?
  • Are the claim types the same?
  • Do they have to do anything to transition over existing users?
  • AppSettings migration (can we make the new sample look as much like the old config as possible?)

 services.AddAuthentication()
            .AddMicrosoftIdentityWebApp(microsoftOptions =>
            {
              microsoftOptions.Instance = "https://login.microsoftonline.com";
              microsoftOptions.TenantId = "consumers";
              microsoftOptions.ClientId = Configuration["Authentication:Microsoft:ClientId"];
            }, cookieScheme = null);

Is this using the id_token flow so the client secret isn't required anymore?

[jennyf19]

@Tratcher will need to talk to @henrik-me and @jmprieur about prioritization w/our other items.

It looks like that will require setting the cookieScheme to null? yes

How to set the display name so this still shows up as Microsoft Account on Identity's external providers page? we need to do this -> issue here.

Is this using the id_token flow so the client secret isn't required anymore? The client secret is only needed if calling a web API or calling Graph, so if just signing-in users, it's not needed. Auth code flow, with response_type=id_token.

For the migration story, I would need time to look at the current one and ours to compare, and that will need to be prioritized, as mentioned above.

[Tratcher]

@blowdart for the prioritization discussion. Since this is doc focused it's not on a strict release deadline, but we'd like to get it done in the .NET 6 time frame (Nov).

[jennyf19]

AddMicrosoftAccountIsDeprecated.md

@Tratcher @blowdart @Rick-Anderson I believe all the questions are answered above. LMK if there is more to do. thanks.

[Tratcher]

I created an aspnetcore 3.1 project template with --auth SingleOrg. I followed this doc, plus this GitHub issue to get things to work.

Ok, I think this is the disconnect, most people using AddMicrosoftAccount aren't using the SingleOrg auth template, they're using the Individual one where MicrosoftAccount isn't the primary authentication provider, it's secondary to the local user database. Users link their MicrosoftAccount to a local user account. If the nameidentifier changes when migrating that's a problem because the accounts won't be linked anymore. It looks like they'll need some more sample code to map the new objectidentifier back to the old nameidentifier to maintain the link.

How to set the display name so this still shows up as Microsoft Account on Identity's external providers page?

• Not sure what this means exactly. But the value for User.Identity.Name is different:

I meant the display name field of the authentication scheme, not the user. See https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.microsoftaccountextensions.addmicrosoftaccount?view=aspnetcore-5.0#Microsoft_Extensions_DependencyInjection_MicrosoftAccountExtensions_AddMicrosoftAccount_Microsoft_AspNetCore_Authentication_AuthenticationBuilder_System_String_System_String_System_Action_Microsoft_AspNetCore_Authentication_MicrosoftAccount_MicrosoftAccountOptions__ that has the overload that accepts a displayName. Identity special cases schemes with a display name set so they show up as external login providers on the sign-in page.

[FranklinWhale]

I hope the doc will show how to use AddOpenIdConnect instead of Identity.Web. Identity.Web requires EnableTokenAcquisitionToCallDownstreamApi to use the authorization code flow (which then requires token storage), adds offline_access to scope unnecessarily and breaks the AuthenticationBuilder chain. AddOpenIdConnect should be used for simple authentication, and the following code should work very similar to AddMicrosoftAccount:

.AddOpenIdConnect("Microsoft", "Microsoft", options => {
    options.Authority = "https://login.microsoftonline.com/common/v2.0/";
    options.ClientId = Configuration["Authentication:Microsoft:ClientId"];
    options.ClientSecret = Configuration["Authentication:Microsoft:ClientSecret"];
    options.ResponseType = OpenIdConnectResponseType.Code;
    options.CallbackPath = "/signin-microsoft";
    options.TokenValidationParameters.IssuerValidator = AadIssuerValidator.GetAadIssuerValidator("https://login.microsoftonline.com/").Validate;
})

[Rick-Anderson]

Email sent to @jennyf19

[chucklu]

@Tratcher any update on this topic? should we use AddMicrosoftIdentityWebApp instead of AddMicrosoftAccount

also filed an discussion here https://github.com/dotnet/aspnetcore/discussions/49484