How to Implement and Validate JWT Authentication in ASP.NET MVC

Implementing JWT authentication in an ASP.NET application means two distinct pieces working together: an endpoint that issues tokens after verifying a user's credentials, and middleware configuration that validates incoming tokens on every subsequent authenticated request. Most implementation problems come from misconfiguring the second piece, not from generating tokens incorrectly in the first place.

Token generation itself, using the System.IdentityModel.Tokens.Jwt package, involves building a list of claims (typically including the user's ID and any roles or permissions relevant to your application), creating signing credentials from a secret key and chosen algorithm, and using a JwtSecurityTokenHandler to produce the final signed token string, along with setting an appropriate, deliberately short expiration time rather than leaving tokens valid indefinitely.

On the validation side, ASP.NET's JWT bearer authentication middleware needs to be configured with TokenValidationParameters that explicitly specify what a valid token must satisfy — the correct issuer, the correct audience, the exact signing key to verify against, and whether to validate the token's expiration. Leaving any of these unconfigured or set to false — validateIssuer or validateAudience disabled, for instance — weakens the security guarantees of the entire scheme, sometimes without producing any obvious error, since a permissively configured validator will happily accept tokens that shouldn't be considered valid.

A specific, very common configuration mistake is mismatching the signing key format between token generation and validation — the key used to sign a token and the key configured for validating it need to represent the exact same underlying secret, but it's easy to accidentally construct them differently (different byte encoding, extra whitespace from a configuration file, or pulling from two different environment variables that were meant to be the same value) and end up with every token failing validation despite looking correctly formed.

The [Authorize] attribute on your MVC controllers or actions is what actually triggers the JWT bearer middleware to validate the incoming token for a given request — it's worth confirming this attribute is present on every route that should require authentication, since a route without it will happily process a request even with no token attached, or a completely invalid one, since there's nothing telling ASP.NET to check.

For role or permission-based authorization on top of basic authentication, claims embedded in the JWT itself — like a role claim — can be checked directly with [Authorize(Roles = "Admin")] or a custom authorization policy, but this depends on your token generation code actually including those claims in the first place; a very common bug is expecting role-based authorization to work when the token generation logic never added a role claim to begin with, silently failing every authorization check that depends on it.

Refresh tokens deserve separate, deliberate design rather than being bolted on as an afterthought — since access tokens should be short-lived, you need a secure mechanism for issuing new ones without forcing the user to log in again constantly, typically a longer-lived refresh token stored securely (an HttpOnly cookie, not local storage) that your token endpoint can exchange for a fresh access token, with its own separate expiration and revocation handling.

When debugging why a token that looks correctly formed is still being rejected, decoding it independently of your ASP.NET application — to confirm exactly what claims, issuer, audience, and expiration it actually contains — isolates whether the problem is in how the token was generated or how it's being validated. Our JWT Decoder shows you the full decoded payload of any token instantly, which is often faster than adding temporary logging statements throughout your authentication middleware to narrow down where the mismatch actually is.