JWT Validation Against an RSA Public Key: The ValidAlgorithms Gotcha

#dotnet #security #oauth

If you're validating JWTs signed with RSA in .NET and getting a signature validation failure even though you're certain the public key is correct, there's a good chance the problem isn't your key at all — it's how you've configured ValidAlgorithms.

The symptom

You set up token validation like this:

var validationParameters = new TokenValidationParameters
{
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = rsaSecurityKey,
    ValidAlgorithms = new[] { "RS256" },
    // ...other parameters
};

The public key is correct. You've verified it against the signing certificate. And yet token validation still fails with a signature error, as if the key were wrong.

The wrong assumption

The natural assumption is that "RS256" is "RS256" — a single, standard algorithm identifier that any RSA-signed JWT will use, and any validator will recognize.

Not every token issuer sends that identifier in the same format.

The actual cause

Some identity providers — particularly older or WCF-based token services — express the signing algorithm as a full URI rather than the short JWT-standard name. Instead of "RS256", the token's header may specify something like "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256". If your ValidAlgorithms list only contains the short-form name, tokens signed with the URI-form algorithm identifier get rejected outright — even though the actual cryptographic signature is completely valid.

The fix

Include both the short-form and URI-form algorithm identifiers in ValidAlgorithms:

var validationParameters = new TokenValidationParameters
{
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = rsaSecurityKey,
    ValidAlgorithms = new[]
    {
        "RS256",
        "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
    },
    // ...other parameters
};

Once both forms are present, tokens get validated correctly regardless of which identifier format the issuing service used to describe its signing algorithm.

The broader lesson

If you're integrating JWT validation with an identity provider you don't fully control — especially anything with roots in WCF or older enterprise SSO systems — don't assume the algorithm identifier will always arrive in the modern short form. Check the actual token header (a JWT decoder makes this trivial) before assuming your key or your validation logic is at fault. A "signature invalid" error can be entirely about algorithm identifier mismatch, with the signature itself being perfectly fine.

DEV Community