Jwt None Algorithm in Aspnet (Csharp)

The JWT None algorithm in an ASP.NET context occurs when a token is accepted without a signature verification, typically because the server validates the token header but does not enforce a signing algorithm. In C#, this can happen when using System.IdentityModel.Tokens.Jwt or Microsoft.AspNetCore.Authentication.JwtBearer without explicitly requiring a signing key and algorithm. If the validation parameters specify SignatureValidator as a delegate that does not check the algorithm, or if TokenValidationParameters are set with ValidateIssuerSigningKey = false, the runtime may accept a token whose header declares alg: "none". An attacker can craft a token with a manipulated payload (e.g., changing roles or user identifiers) and set the header to { "alg": "none", "typ": "JWT" }, then sign it with an empty signature. Because the server does not require a matching signing key, the token is treated as valid. This bypasses authentication and authorization controls, commonly leading to privilege escalation (BOLA/IDOR) and unauthorized access to protected endpoints. The risk is higher when ASP.NET endpoints rely solely on cookie-based sessions or when JWTs are used across services without consistent validation. Attack patterns include token replay and horizontal privilege escalation, where a low-privilege account uses a none-signed token to impersonate an admin. This scenario aligns with OWASP API Top 10 API6:2023 — Broken Function Level Authorization, because missing algorithm checks allow tampering with authorization logic. Detection often requires runtime analysis that maps token validation behavior against expected algorithms, a check included in the LLM/AI Security and Authentication categories of a middleBrick scan, which identifies missing algorithm enforcement and highlights insecure validation delegates in C# applications.

To remediate the JWT None algorithm vulnerability in ASP.NET with C#, explicitly configure token validation to require a known signing algorithm and provide a suitable security key. Below are two common approaches depending on whether you use JWT Bearer authentication or manual token handling.

1. Using JwtBearerDefaults.AuthenticationScheme (recommended for ASP.NET Core)

Configure AddAuthentication with JwtBearerOptions to enforce an algorithm and validate the issuer/audience. This ensures the runtime rejects tokens with alg: "none".

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

// In Program.cs or Startup.cs
builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidIssuer = "https://your-issuer.example.com",
        ValidateAudience = true,
        ValidAudience = "https://your-audience.example.com",
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("YourVeryStrongAndSecretKeyAtLeast32Chars!!")),
        // Explicitly require a signing algorithm
        AllowedSigningAlgorithms = new[] { SecurityAlgorithms.HmacSha256 }
    };
});

With this configuration, tokens that do not use HMAC-SHA256 (or the specified algorithm) will fail validation. The AllowedSigningAlgorithms property ensures that even if a token header specifies another algorithm, it will be rejected.

2. Manual validation with JwtSecurityTokenHandler

If you validate tokens manually (e.g., in a custom middleware or API action), use TokenValidationParameters and avoid delegates that bypass algorithm checks.

using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
using Microsoft.IdentityModel.Tokens;

public bool TryValidateToken(string token, out ClaimsPrincipal principal)
{
    var handler = new JwtSecurityTokenHandler();
    var validationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("YourVeryStrongAndSecretKeyAtLeast32Chars!!")),
        ValidateIssuer = true,
        ValidIssuer = "https://your-issuer.example.com",
        ValidateAudience = true,
        ValidAudience = "https://your-audience.example.com",
        ValidateLifetime = true,
        // Require a specific signing algorithm
        ValidAlgorithms = new[] { SecurityAlgorithms.HmacSha256Signature }
    };

    try
    {
        principal = handler.ValidateToken(token, validationParameters, out _);
        return true;
    }
    catch (SecurityTokenException)
    {
        principal = null;
        return false;
    }
}

In both examples, ensure that the signing key is strong and stored securely, for example using Azure Key Vault or environment variables. Avoid accepting tokens when ValidateIssuerSigningKey is false or when using a custom SignatureValidator that does not verify the algorithm. These changes prevent an attacker from exploiting the None algorithm and mitigate related authentication bypass issues reported in findings from a middleBrick scan, which can map the issue to compliance frameworks such as OWASP API Top 10 and SOC2.