Skip to content

feat: add validateDecoded option for JWT payload validation #377

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

williamfds
Copy link

@williamfds williamfds commented May 29, 2025

This PR introduces a new validateDecoded option to the @fastify/jwt plugin.

It allows developers to define custom validation logic that runs after the JWT is decoded and verified, but before assigning request.user.
This enables scenarios where claims alone are insufficient, such as:

  • Checking flags (e.g., isVerified)

  • Validating roles or permissions

  • Applying business rules or JSON Schema validation

  • Performing async checks (e.g., database lookups)

Example: synchronous usage

fastify.register(jwt, {
  secret: 'supersecret',
  validateDecoded: (payload) => {
    if (!payload.admin) {
      throw new Error('Not authorized')
    }
  }
})

Example: asynchronous usage

fastify.register(jwt, {
 secret: 'supersecret',
 validateDecoded: async (payload) => {
   const isAllowed = await someCheck(payload.userId)
   if (!isAllowed) {
     throw new Error('Blocked by validation')
   }
 }
})

Implementation notes

This change includes the following:

  • Adds validateDecoded(payload) support to plugin options

  • Executed after token verification in request.jwtVerify()

  • If validation fails, responds with 400 Bad Request

  • Includes test coverage for both sync and async cases

  • Type definitions updated (types/jwt.d.ts)

  • Documentation updated in README.md

Related

Checklist

Copy link
Member

@jsumners jsumners left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is a good idea. The issuance of a JWT should be done after the client has been authenticated and authorized. This seems to be adding authorization functionality into the JWT validation process. I think that is probably a bad practice.

If this change is warranted, I think the naming of the option is not clear enough. And this is definitely missing required documentation.

@jsumners jsumners requested a review from mcollina May 29, 2025 01:39
@williamfds williamfds closed this May 29, 2025
@williamfds williamfds deleted the feat/validate-option branch May 29, 2025 13:56
@williamfds williamfds reopened this May 30, 2025
@williamfds williamfds changed the title feat: add validate option to validate JWT payload feat: add validateDecoded option to validate JWT payload May 30, 2025
@williamfds williamfds requested a review from jsumners May 30, 2025 13:41
@williamfds williamfds changed the title feat: add validateDecoded option to validate JWT payload feat: add validateDecoded option for JWT payload validation May 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add 'validate' option to allow token claim validation
2 participants