---
title: "Comment by Azhar Abbas on \"Why ASP.NET Core Accepts Expired JWTs (And How to Fix It)\" | Hashnode"
description: "The comparison table makes the cross-service mismatch clear. One distinction worth adding: reducing clock skew tightens expiry enforcement, but it doesn't revok"
url: "https://hashnode.com/posts/why-aspnet-core-accepts-expired-jwts/6af58b784b90906ebc6a38e2/comment/6af6e4df2fcd624dfa1cdc05"
---

[Discussion](https://hashnode.com/posts/why-aspnet-core-accepts-expired-jwts/6af58b784b90906ebc6a38e2)

Comment [Why ASP.NET Core Accepts Expired JWTs (And How to Fix It)](https://hashnode.com/posts/why-aspnet-core-accepts-expired-jwts/6af58b784b90906ebc6a38e2)

[Azhar Abbas](https://hashnode.com/@azharabbas)

[11h ago](https://hashnode.com/posts/why-aspnet-core-accepts-expired-jwts/6af58b784b90906ebc6a38e2/comment/6af6e4df2fcd624dfa1cdc05)

The comparison table makes the cross-service mismatch clear. One distinction worth adding: reducing clock skew tightens expiry enforcement, but it doesn't revoke a token before its expiry. Immediate logout or incident response still needs a separate revocation strategy. I'd add boundary tests around both exp and nbf, with the chosen leeway, so a configuration change doesn't silently accept tokens early or reject valid ones across services.