Unable to retrieve OpenID configuration for Apple

[appimpact]

Describe the bug

After recent updates, sign in with Apple is no longer working on any of our apps. Users are taken to point where they authenticate, provide consent, and after that an error is returned:

IDX20803: Unable to obtain configuration from: 'https://appleid.apple.com/.well-known/openid-configuration'

We have tested URL from error and it is accessible from our hosting servers internally so there is no firewall or connection issue. When URL is open in browser, it shows OpenID configuration as it should.

Steps To reproduce

There are no particular steps to reproduce here. Sign in is working, but retreiving of OpenID configuration is not.

Expected behaviour

Middleware should process callback.

Actual behaviour

Middleware fails on retreiving OpenID configuration and throws an error.

System information

• OS: Windows Server 2019
• .NET version: 7.0.11

Additional context

We are using AspNet.Security.OAuth.Apple version 7.0.4 (latest).

[martincostello]

Could you provide some error logs showing the failure or other information please?

I have a sample app integrated with Sign In With Apple with the latest versions of ASP.NET Core 7 and our provider and it is working as expected.

[appimpact]

@martincostello The error we receive is the one mentioned in the issue:

IDX20803: Unable to obtain configuration from: 'https://appleid.apple.com/.well-known/openid-configuration'

It seems as if middleware fails to access URL from some reason.

There were no changes in either code or server infrastructure that could have caused this - except for the update to .NET and auth libraries.

We will try to get more information about error context and get back to you.

[appimpact]

@martincostello Here is the error log:

IDX20803: Unable to obtain configuration from: 'https://appleid.apple.com/.well-known/openid-configuration'. => Could not load type 'Microsoft.IdentityModel.Json.JsonConvert' from assembly 'Microsoft.IdentityModel.Tokens, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.\",\r\n \"fileLineNumber\": 0,\r\n \"innerStackTrace\": \" at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel)\r\n at AspNet.Security.OAuth.Apple.Internal.DefaultAppleIdTokenValidator.ValidateAsync(AppleValidateIdTokenContext context)\r\n at AspNet.Security.OAuth.Apple.AppleAuthenticationEvents.<>c.<<-ctor>b__10_1>d.MoveNext()\r\n--- End of stack trace from previous location ---\r\n at AspNet.Security.OAuth.Apple.AppleAuthenticationEvents.ValidateIdToken(AppleValidateIdTokenContext context)\r\n at AspNet.Security.OAuth.Apple.AppleAuthenticationHandler.CreateTicketAsync(ClaimsIdentity identity, AuthenticationProperties properties, OAuthTokenResponse tokens)\r\n at AspNet.Security.OAuth.Apple.AppleAuthenticationHandler.HandleRemoteAuthenticateAsync(Dictionary2 parameters)\\r\\n at AspNet.Security.OAuth.Apple.AppleAuthenticationHandler.HandleRemoteAuthenticateAsync()\\r\\n at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler1.HandleRequestAsync() `

Seems that it is related to Microsoft.IdentityModel.Tokens library where it is attempting to load Microsoft.Identity.Json.JsonConvert object, however we could not find that class on the github for their latest release.

[martincostello]

Looks like there was a breaking change made in v7 of the .NET JWT libraries.

Either it's a bug, in which case you should report it in their repo, or it's an intentional change in which case you need to downgrade the library back to v6 in your application.

We can update our dependency to v7 as part of our forthcoming v8 release, but updating the code one our end to use v7 would be a breaking change.

[kevinchalet]

Seems that it is related to Microsoft.IdentityModel.Tokens library where it is attempting to load Microsoft.Identity.Json.JsonConvert object, however we could not find that class on the github for their latest release.

That's because Wilson 7.0 moved from an internal copy of JSON.NET to the public System.Text.Json APIs.

Do you reference System.IdentityModel.Tokens.Jwt (directly or transitively)? If so, try bumping the reference to 7.0.0 to see if it helps.

[appimpact]

@kevinchalet We had System.IdentityModel.Tokens.Jwt referenced directly to latest version 7.0.0.

@martincostello We did rollback of both packages to latest 6.32.3 version as a workaround and error is no longer appearing. Two mentioned packages are: Microsoft.IdentityModel.Tokens System.IdentityModel.Tokens.Jwt

We have also tested other providers (Microsoft, Google, LinkedIn) and those are working correctly, probably as MS is maintaining them and those don't have direct dependency on mentioned libraries.

[martincostello]

Double-checking our code, we don't explicitly reference either library, we just get the reference transitively from ASP.NET Core so we compile/depend on the version that ASP.NET Core itself ships with.

This means for our v7 libraries it's 6.x.x and for our forthcoming v8 release it will be 7.0.0.

Looks like you'll need to upgrade to ASP.NET Core 8 to use the 7.0.0 version of those two libraries with our providers.

[kevinchalet]

FWIW, I spent quite some time testing all the ASP.NET Core/IdentityModel versions combinations when they announced Wilson 7.0 would be breaking (kudos to them for being attentive to the community feedback) and the key point is to ensure all the System.IdentityModel and Microsoft.IdentityModel packages have the same exact version.

In your case, it really sounds like you have an issue with one of the Microsoft.IdentityModel packages (maybe Microsoft.IdentityModel.Protocols or Microsoft.IdentityModel.Protocols.OpenIdConnect?)

[martincostello]

Looks like someone else has hit a similar issue here: https://github.com/dotnet/aspnetcore/issues/50943

[kevinchalet]

Yeah, looks like reports are piling up: https://matrix.to/#/!DYBDMbtjENXaKIMiCN:gitter.im/$YBKLds5uHyLw7wRLju1wgd7IFvj5pDmGBxpcHAdilBQ?via=gitter.im&via=matrix.org 😅

(not sure why it's suddenly happening, Wilson 7.0 was released 2 weeks ago 😄)

[kevinchalet]

Closing, as there isn't much we can do on our side.