SecurityTokenInvalidIssuerException with OpenID Connect and the Azure AD "common" endpoint

[fschmied]

When you use OpenID Connect against Azure AD's "common" endpoint, configuring https://login.microsoftonline.com/common/v2.0 as the OpenIdConnectOptions.Authority value, the metadata document will provide an issuer value of https://login.microsoftonline.com/{tenantid}/v2.0. Note the "{tenantid}" placeholder.

Within an actual ID token, the issuer value no longer contains that placeholder, but the actual tenant ID determined by the user logging in (e.g., https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0). This causes the issuer validation in Microsoft.IdentityModel.Tokens to fail.

I guess Azure AD decided to return an issuer with a non-standard (?) placeholder here, but shouldn't the code in
azure-activedirectory-identitymodel-extensions-for-dotnet be able to deal with such Azure AD specifics? If so, I'd consider this a bug.

Also, the exception message is IDX10205: Issuer validation failed. Issuer: 'System.String'. Did not match: validationParameters.ValidIssuer: 'System.String' or validationParameters.ValidIssuers: 'System.String'. Which is not at all helpful, but I'll open a separate issue for this.

[fschmied]

For anyone reading this and needing a workaround: see Thomas Levesque's post on this issue: https://thomaslevesque.com/2018/12/24/multitenant-azure-ad-issuer-validation-in-asp-net-core/

[jennyf19]

This issue will be resolved when Microsoft.IdentityModel picks up the AadIssuerValidator from Microsoft.Identity.Web. We are in the process of moving it over now. Should be in next IdentityModel release hopefully.

[fschmied]

@jennyf19 Wow, thanks for fixing this so fast. Will this new AadIssuerValidator be present automatically, i.e., can I just wire up authentication with Azure AD in multitenant mode by setting the OpenIdConnectOptions in appsettings.json? Or will I still need to programmatically set an IssuerValidator?

Appsettings.json would be awesome - that's how it works with every standard OIDC implementation.

[jennyf19]

@fschmied Depends on if you are ASP.NET or ASP.NET Core. If on ASP.NET, yes, you have to still set them programmatically. If on ASP.NET Core, you can use Microsoft.Identity.Web, which provides a higher-level API and does this automatically for you.

[fschmied]

@jennyf19 I use this library only indirectly, via Microsoft.AspNetCore.Authentication.OpenIdConnect (which in turn depends on Microsoft.IdentityModel.Protocols.OpenIdConnect).

So, I'm calling services.AddAuthentication()...AddOpenIdConnect(), and I'm configuring everything in appsettings.json via OpenIdConnectOptions. That way, I can use any OpenID Connect identity provider. (Just not Azure AD's common endpoint because that one requires that nonstandard issuer validation.)

I guess in that scenario, the common endpoint would still not work out of the box, even after #1736, right? I'd need to wire up the new validator in code, not in configuration?

[jennyf19]

@fschmied this should work

services.Configure<JwtBearerOptions>(JwtBearerDefaults.AuthenticationScheme, options =>
{
    options.TokenValidationParameters.ValidateIssuer = AadIssuerValidator.GetAadIssuerValidator(authority).Validate;
});

And you could use OpenIdConnectOptions instead. Are you validating the IdToken in that case?

[fschmied]

@jennyf19 Thanks for the pointer (and sorry for the delay). My point was that using the validator will not be possible using appsettings.json. So, if we want to support Azure AD multitenancy, we'll have to adapt our application code.

Also thank you for the quick reaction!