#Passport - Is validate method necessary if I'm validating everything through jsonWebTokenOptions?

12 messages · Page 1 of 1 (latest)

rough rose
#

I'm trying to simplify our existing guard and strategy since it seems there is a lot of bloat that is unnecessary. I'm having a bit of a hard time figuring out what parts are bloat and what parts are necessary though.

The validate method of our strategy looked something like this:

async validate(payload?: JwtPayload): Promise<JwtPayload> {
  if (!payload) {
    throw new UnauthorizedException();
  }
  if (payload.iss !== 'Issuer') {
    throw new UnauthorizedException();
  }

  return payload;
}

I looked through the NestJS/Passport code and it looks like there is no instance where payload would be falsy. Aside from that, I am taking care of validating the issuer by specifying it in jsonWebTokenOptions.

So it seems like the new method should just be:

async validate(payload: JwtPayload): Promise<JwtPayload> {
  return payload;
}

But something feels wrong with that considering validate was defined as an abstract method instead of having that be the default.

Is there anything wrong with doing that, or is that normal enough for a simple strategy?

hot thicket
#

If you've configured jsonWebTokenOptions (e.g., issuer, audience, algorithms, etc.), then many of the checks that were previously in the validate method (like checking the issuer) are redundant.
Since Passport and passport-jwt will reject invalid tokens before they reach the validate method, there's no need to check for a falsy payload unless you're dealing with a custom edge case.

#

If then, why Is validate Abstract?
The validate method is abstract because it's meant to be a hook for additional validation or user fetching logic.
While passport-jwt extracts the payload, NestJS gives you a chance to:

  • Fetch user details from a database (if needed)
  • Apply extra role-based or permissions logic
  • Implement business-specific security constraints
#

And then

#

You will be asked like this: Is It Safe to Just Return the Payload?

#

If you don't need to enrich the payload like fetching user details or applying extra checks beyond what JWT options handle, returning the payload directly is completely fine.
However, be cautious about blindly trusting JWT claims without checking against your user database like handling revoked users or changed roles.

#

async validate(payload: JwtPayload): Promise<JwtPayload> {
return payload; // Simplified validation if JWT options handle everything
}

#

Just, If your app needs to fetch additional user data (e.g., roles, permissions) before setting req.user, you should use the validate method for that

#

.

async validate(payload: JwtPayload): Promise<User> {
const user = await this.userService.findById(payload.sub);
if (!user) {
throw new UnauthorizedException();
}
return user;
}

#

✅ Anyway, it's perfectly normal to just return payload if all necessary validation is handled by jsonWebTokenOptions.
🔍 But if you anticipate future changes like user role checks, revoked users, or database lookups, leaving a simple validate method stub could be helpful.

rough rose
#

That makes sense, thanks!