1

Briefly

Should I be using OpenIdConnectDefaults.AuthenticationScheme when authenticating with Azure ADFS?

In more detail

I have an ASP.NET Core application that has recently been upgraded from 3.1 to .NET 5.

Previously, it had been using the following NuGet package:

<PackageReference Include="Microsoft.AspNetCore.Authentication.AzureAD.UI" Version="3.1.9" />

and the following in my StartUp.cs:

services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
    .AddAzureAD(options => this.Configuration.Bind("AzureAd", options));

Today, I updated the NuGet package:

<PackageReference Include="Microsoft.AspNetCore.Authentication.AzureAD.UI" Version="5.0.3" />

And immediately received warnings that I was using deprecated/obsolete code.

I was directed to the Microsoft Identity Web page for more information....seemed like a lot to trawl through to find what I wanted.

I did read though that the Visual Studio Preview version had an updated Project Template, so I created a new project and this connected to Azure and I was logged in with my domain credentials. Fantastic!

The relevant NuGet packages it used appear to be:

<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="5.0.3" NoWarn="NU1605" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="5.0.3" NoWarn="NU1605" /
<PackageReference Include="Microsoft.Identity.Web" Version="1.1.0" />
<PackageReference Include="Microsoft.Identity.Web.UI" Version="1.1.0" />

So, Authentication done. Now onto Authorization.....

So we have our own home-grown Authorization service. We send the user's identity (from ADFS) to this and it returns what they're allowed to do. This is where things broke....

Our original code for this used the "Upn" claim from the response from Azure ADFS:

Claim? upnClaim = identity.FindFirst(ClaimTypes.Upn);

This returns the claim with the email address.

However, this now returned null.

The following code did get the claim with the email address:

Claim? upnClaim = identity.FindFirst("preferred_username");

So, I could run with this and it would work.....

However, I would like to know if using OpenIdConnectDefaults.AuthenticationScheme is the preferred option for the latest Microsoft Identity and Azure ADFS? The fact that I'm having to use a magic string "preferred_username" rather than ClaimTypes.Upn gives me some doubt.

Does anyone have any deep insight into this?

DrGriff
  • 4,394
  • 9
  • 43
  • 92

1 Answers1

1

The fact that I'm having to use a magic string "preferred_username" rather than ClaimTypes.Upn gives me some doubt.

preferred_username is not a magic string, it's documented as one of the claims that AAD adds to the id token payload, see https://learn.microsoft.com/azure/active-directory/develop/id-tokens#payload-claims.

The underlying library used by the ASP.NET Core OpenID Connect provider used to map claims to match well-known claims in the .NET world. Maybe Microsoft.Identity.Web disables that specific behaviour.

I blogged about this a while back at https://mderriey.com/2019/06/23/where-are-my-jwt-claims/.

Mickaël Derriey
  • 12,796
  • 1
  • 53
  • 57
  • Been reading through the links - very helpful. I see that Microsoft recommend using an immutable and non-human-readable claims such as the `oid` to identify the user for Authorization purposes. I fully understand that. However, how can I find out my colleagues `oid` values? I don't have domain-admin rights. The cmd `net user username /domain` doesn't appear to return this. – DrGriff Feb 23 '21 at 15:48
  • 1
    If you log in to the Azure portal at https://portal.azure.com > Azure Active Directory > Users > search for someone > click on their profile, you should be able to see it. – Mickaël Derriey Feb 23 '21 at 18:13
  • It's also possible to get this information using PowerShell's `Get-AzureADUser` – DrGriff Feb 25 '21 at 13:10