Blazor .NET 8 Error

[jmiller76]

Describe the bug?

After updating to 4.6, my Blazor app is failing to authenticate.
Can reproduce with .NET 6 Sample code (after upgrading to .NET 8)

What is expected to happen?

Authentication

What is the actual behavior?

An unhandled exception occurred while processing the request.
SecurityTokenException: The Validated Security Token must be of type JsonWebToken, but instead its type is 'System.IdentityModel.Tokens.Jwt.JwtSecurityToken'.
Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.ValidateTokenUsingHandlerAsync(string idToken, AuthenticationProperties properties, TokenValidationParameters validationParameters)

AuthenticationFailureException: An error was encountered while handling the remote login.
Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler.HandleRequestAsync()

Reproduction Steps?

Pull https://github.com/okta/samples-blazor, use Upgrade Assistant to move the demo to .NET 8.
Update Appsettings to working API keys
Test - All works
Update NuGet package Okta.AspNetCore to 4.6.0
Test - Above Error show

Additional Information?

No response

.NET Version

8.0.200

SDK Version

4.6

OS version

BuildNumber Caption OSArchitecture Version
22631 Microsoft Windows 11 Enterprise 64-bit 10.0.22631

[laura-rodriguez]

Thanks for reporting this issue @jmiller76!

Possible duplicated of #259

[jmiller76]

Possibly, I am monitoring that one too.

The error seemed different enough that I thought it may be a different use case.

This also produces with a less complicated AddOktaMvc. If there is a common problem that may help.

I think this may help too.

[yongkeecho]

The issues were gone when all the venerable versions are updated to the latest ones. But I still had an issue with 4.6.0 in the previous post.

[THJeffJ]

It looks like this is related to a .NET 8 behavior breaking change - Security token events return a JsonWebToken

[GeoRHeld]

Having this same issue when upgrading to 4.6.0 on an ASP.NET 8.0 Razor Pages project. Downgrading to 4.5.0 works with the "fix" described in issue #259 .

[THJeffJ]

@laura-rodriguez Reverting to using SecurityTokenValidators in OpenIdConnectOptions and JwtBearerOptions within OpenIdConnectOptionsHelper as described in the MS article above will resolve this. I tested this change briefly. #259 appears to be a different issue.

[Mark-Good]

This issue is not limited to Blazor. It is also impacting my ASP.NET Core MVC application in the same way as described.

[davidcorbin-atmosera]

Note: The Okta provided sample:
https://github.com/okta/samples-blazor

Is a reproducible link once upgraded!!!

[lymberl]

@THJeffJ Were you able to fix this issue by reverting to using SecurityTokenValidators? Are you able to post the code for this?

[davidcorbin-atmosera]

Note: The Okta provided sample: https://github.com/okta/samples-blazor

Is a reproducible link once upgraded!!!

@lymberl - Please note, that:

1. I was NOT able to find a way to set the parameter to use the old method (I spotted the conditional in the Okta source), but if I did modify the Okta source to set it [unacceptable] the program 'worked".
2. Using the old Token types leaves open a known security hole [as does reverting back to Okta 4.5] that has been documented: https://github.com/advisories/GHSA-59j7-ghrg-fj52 int he current referenced Microsoft asemble. This is also unacceptable from a security standpoint...

As far as I can tell [and I am not claiming expertise] there needs to be a way to configure the Okta side of things [aka the application] that it shoudl return the new type of token rather than the old.....and then ALSO update Okta so it does not pull in old [2022] assemblies with known security alerts...

[NickDrouin]

Same issue, here's my notes:

Microsoft.AspNetCore.Authentication.AuthenticationFailureException: An error was encountered while handling the remote login.
 ---> Microsoft.IdentityModel.Tokens.SecurityTokenException: 
 The Validated Security Token must be of type JsonWebToken, but instead its type is 'System.IdentityModel.Tokens.Jwt.JwtSecurityToken'.
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.ValidateTokenUsingHandlerAsync(String idToken, AuthenticationProperties properties, TokenValidationParameters validationParameters)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleRemoteAuthenticateAsync()
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

Seems related to this:
https://learn.microsoft.com/en-us/dotnet/core/compatibility/aspnet-core/8.0/securitytoken-events

Which seems known by Okta: #260

The failure is at: OpenIdConnectHandler.cs#L532

				if (!base.Options.UseSecurityTokenValidator)
				{
					TokenValidationResult obj = await ValidateTokenUsingHandlerAsync(tokenEndpointResponse2.IdToken, properties, validationParameters);
					user4 = new ClaimsPrincipal(obj.ClaimsIdentity);
					jwt3 = JwtSecurityTokenConverter.Convert(obj.SecurityToken as JsonWebToken);
				}
				else
				{
					user4 = ValidateToken(tokenEndpointResponse2.IdToken, properties, validationParameters, out jwt3);
				}

Where: Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectOptions.UseSecurityTokenValidator==false

_Note: If UseSecurityTokenValidator is set to true in debug, we login without issues.

The error is in the delegate to Okta within:

	private async Task<TokenValidationResult> ValidateTokenUsingHandlerAsync(string idToken, AuthenticationProperties properties, TokenValidationParameters validationParameters)
	{
		if (base.Options.ConfigurationManager is BaseConfigurationManager configurationManager)
		{
			validationParameters.ConfigurationManager = configurationManager;
		}
		else if (_configuration != null)
		{
			string[] array = new string[1] { _configuration.Issuer };
			validationParameters.ValidIssuers = validationParameters.ValidIssuers?.Concat(array) ?? array;
			validationParameters.IssuerSigningKeys = validationParameters.IssuerSigningKeys?.Concat(_configuration.SigningKeys) ?? _configuration.SigningKeys;
		}
		TokenValidationResult tokenValidationResult = await base.Options.TokenHandler.ValidateTokenAsync(idToken, validationParameters);

Where base.Options.TokenHandler is of type: {Okta.AspNet.Abstractions.StrictTokenHandler}
With:

•   TokenType	{Name = "JwtSecurityToken" FullName = "System.IdentityModel.Tokens.Jwt.JwtSecurityToken"}	System.Type {System.RuntimeType}
  

The code continues with:

		if (tokenValidationResult.Exception != null)
		{
			throw tokenValidationResult.Exception;
		}
		SecurityToken securityToken = tokenValidationResult.SecurityToken;
		if (!tokenValidationResult.IsValid || securityToken == null)
		{
			base.Logger.UnableToValidateIdTokenFromHandler(idToken);
			throw new SecurityTokenException(string.Format(CultureInfo.InvariantCulture, Resources.UnableToValidateTokenFromHandler, idToken));
		}
		if (!(securityToken is JsonWebToken))
		{
			base.Logger.InvalidSecurityTokenTypeFromHandler(securityToken?.GetType());
			throw new SecurityTokenException(string.Format(CultureInfo.InvariantCulture, Resources.ValidatedSecurityTokenNotJsonWebToken, securityToken?.GetType()));
		}
		

Where securityToken is of type Microsoft.IdentityModel.Tokens.SecurityToken {System.IdentityModel.Tokens.Jwt.JwtSecurityToken}

So the following is logged:

Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler: Error: The Validated Security Token must be of type JsonWebToken, but instead its type is: 'System.IdentityModel.Tokens.Jwt.JwtSecurityToken.'

And the code throws.

In my case, I created a new net8.0 Blazor project, server-side only, and manually applied all the changes using the github sample (the sample github project is way out of date compared to the latest dotnet new for such a project).

[NickDrouin]

Following on, here is my work-around:

In my Program.cs:

             // Add Okta Auth:
            builder.Services.AddAuthentication(options =>
                {
                    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
                })
                .AddCookie()
                .AddOktaMvc(new OktaMvcOptions
                {
                    // Replace the Okta placeholders in appsettings.json with your Okta configuration.
                    OktaDomain = builder.Configuration.GetValue<string>("Okta:OktaDomain"),
                    ClientId = builder.Configuration.GetValue<string>("Okta:ClientId"),
                    ClientSecret = builder.Configuration.GetValue<string>("Okta:ClientSecret"),
                    AuthorizationServerId = builder.Configuration.GetValue<string>("Okta:AuthorizationServerId"),
                    OpenIdConnectEvents = new OpenIdConnectEvents()
                     {                        
                        OnTokenResponseReceived = async context =>
                        {
                            // Make our own call to Okta.AspNet.Abstractions.StrictTokenHandler
                            // First setup the parameterization as per OpenIdConnectHandler.cs:
                            var _configuration = context.Options.Configuration;
                            TokenValidationParameters validationParameters = context.Options.TokenValidationParameters.Clone();
                            validationParameters.RequireSignedTokens = false;
                            if (context.Options.ConfigurationManager is BaseConfigurationManager configurationManager)
                            {
                                validationParameters.ConfigurationManager = configurationManager;
                            }
                            else if (_configuration != null)
                            {
                                string[] array = new string[1] { _configuration.Issuer };
                                validationParameters.ValidIssuers = validationParameters.ValidIssuers?.Concat(array) ?? array;
                                validationParameters.IssuerSigningKeys = validationParameters.IssuerSigningKeys?.Concat(_configuration.SigningKeys) ?? _configuration.SigningKeys;
                            }
                            string idToken = context.TokenEndpointResponse.IdToken;
                            
                            // Call the validation and check
                            TokenValidationResult tokenValidationResult = await context.Options.TokenHandler.ValidateTokenAsync(idToken, validationParameters);
                            if (tokenValidationResult.Exception != null)
                            {
                                throw tokenValidationResult.Exception;
                            }

                            // Since we have already done the validation, avoid doing again with the net8.0 code
                            // which throws because of Okta's use of JwtSecurityToken instead of JsonWebToken:
                            context.Options.UseSecurityTokenValidator = true;
                        }
                     },
                });
            // To pick up AccountController:
            builder.Services.AddControllers();

Obviously, it doesn't solve the core issue within the Okta library, but I think it does a reasonable job at validating both within the Okta lib, and the secondary validation using the bypass path in net8.0 for JwtSecurityToken.

This code isn't in production, so my security bar is much lower than some readers. Use at your own risks and perils.

[davidcorbin-atmosera]

> Following on, here is my work-around:
@NickDrouin - Your analysis basically matches mine... However, I am not sure I see that as a work around [it is effectively reverting back to the Okta 4.5 behavior, using the old type of tokens, which I believe (and upon a re-read also see you mention) brings back the security issue of:
(Note this gets flagged as a security issue until Okta is updated to NOT reference that Microsoft DLL. But at least in the broken case, the insecure code is not actively executed.
It would seem that the "solution" is to update the Okta Authentication serverso that it returns the newer (and more secure/performant) token returned when one authenticates against: https://dev-4xxxxxxxx.okta.com/.....