fix: normalize expired token error in GetClaimsFromJWT to ErrExpiredToken#30
Open
masonsxu wants to merge 1 commit into
Open
Conversation
…oken GetClaimsFromJWT returns the raw *jwt.ValidationError from ParseToken when a token is expired. This makes it impossible for downstream HTTPStatusMessageFunc to identify expired tokens via == ErrExpiredToken, since *jwt.ValidationError and the sentinel ErrExpiredToken are different types. CheckIfTokenExpire already handles this correctly by checking validationErr.Errors == jwt.ValidationErrorExpired and continuing execution. However, GetClaimsFromJWT lacks the same normalization, causing an inconsistency between the auth flow and the refresh flow. This fix normalizes *jwt.ValidationError with only ValidationErrorExpired to the sentinel ErrExpiredToken in GetClaimsFromJWT, making error handling consistent across both paths. Before this fix: - middlewareImpl receives *jwt.ValidationError for expired tokens - HTTPStatusMessageFunc cannot match it with == ErrExpiredToken - The manual exp check in middlewareImpl (lines 475-496) is dead code for expired tokens since GetClaimsFromJWT already returns an error After this fix: - middlewareImpl receives ErrExpiredToken for expired tokens - HTTPStatusMessageFunc can correctly identify expired tokens
ef75286 to
515000b
Compare
This was referenced Mar 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
GetClaimsFromJWTreturns the raw*jwt.ValidationErrorfromParseTokenwhen a token is expired. This makes it impossible for downstreamHTTPStatusMessageFuncto identify expired tokens via== ErrExpiredToken, since*jwt.ValidationErrorand the sentinelErrExpiredTokenare different types.Root Cause
CheckIfTokenExpire(used in the refresh flow) already handles this correctly:However,
GetClaimsFromJWT(used in the auth flow viamiddlewareImpl) lacks the same normalization:Impact
Inconsistent error types:
middlewareImplreceives*jwt.ValidationErrorfor expired tokens, whileErrExpiredTokenis the documented sentinel error. CustomHTTPStatusMessageFuncimplementations that checkerr == ErrExpiredTokenwill never match.Dead code in
middlewareImpl: The manualexpcheck (lines 475-496) is unreachable for expired tokens becauseGetClaimsFromJWTalready returns an error before claims are available:Fix
Normalize
*jwt.ValidationErrorwith onlyValidationErrorExpiredto the sentinelErrExpiredTokeninGetClaimsFromJWT, consistent withCheckIfTokenExpirebehavior.Testing
All existing tests pass. The fix is backward-compatible — only the error type changes from
*jwt.ValidationErrortoErrExpiredTokenfor the specific case of expired tokens. Both error types have the same semantic meaning ("token is expired"), butErrExpiredTokenis the expected sentinel value that users compare against.