NestJS 9: Enforcing Least‑Privilege Authentication with Expired Tokens

Answer

The cleanest way to enforce least‑privilege when a JWT is expired or revoked is to insert a revocation check before any role evaluation in the guard pipeline. Implement a custom AuthGuard that validates the token, extracts its jti, queries a fast revocation store (Redis), and throws a distinct UnauthorizedException for revoked tokens. Then extend RolesGuard to call the same revocation service before matching roles, guaranteeing that a revoked token never passes role checks.

Why this works

• Separation of concerns – token validity (signature, expiry) stays in JwtStrategy; revocation lives in a dedicated service.
• Distinct errors – the custom guard can return Token expired vs Token revoked, letting clients react differently.
• Least‑privilege preserved – revoked tokens are denied even if they contain valid roles.

Implementation steps

1. Add a jti claim when signing

   JwtModule.register({
     secret: process.env.JWT_SECRET,
     signOptions: { expiresIn: '15m', jwtid: () => uuidv4() },
   });

2. Create RevocationService (Redis)

   @Injectable()
   export class RevocationService {
     constructor(@Inject('REDIS_CLIENT') private redis: Redis) {}
   
     async revoke(jti: string, ttlSeconds: number) {
       await this.redis.set(`revoked:${jti}`, '1', 'EX', ttlSeconds);
     }
   
     async isRevoked(jti: string): Promise {
       return (await this.redis.exists(`revoked:${jti}`)) === 1;
     }
   }

3. Custom JwtAuthGuard

   @Injectable()
   export class JwtAuthGuard extends AuthGuard('jwt') {
     constructor(private revocation: RevocationService) {
       super();
     }
   
     async handleRequest(err, user, info) {
       if (err || !user) throw err || new UnauthorizedException('Token expired');
       const jti = user.jti;
       if (await this.revocation.isRevoked(jti)) {
         throw new UnauthorizedException('Token revoked');
       }
       return user;
     }
   }

4. Extend RolesGuard

   @Injectable()
   export class RolesGuard implements CanActivate {
     constructor(private revocation: RevocationService) {}
   
     async canActivate(ctx: ExecutionContext): Promise {
       const req = ctx.switchToHttp().getRequest();
       const user = req.user;
       if (!user) return false;
       if (await this.revocation.isRevoked(user.jti)) return false;
       const required = this.reflector.get('roles', ctx.getHandler());
       return required.some(r => user.roles.includes(r));
     }
   }

5. Apply guards in order

   @UseGuards(JwtAuthGuard, RolesGuard)
   @Roles('admin')
   @Get('admin')
   async adminRoute() { … }

Persistence layer recommendation

Redis is optimal: O(1) lookup, automatic key expiry matching token TTL, and negligible latency for high‑traffic APIs. If Redis is unavailable, a relational DB with an indexed jti column works but adds latency.

One diagnostic detail needed

Do your issued JWTs already contain a unique jti claim? If not, you must add it (step 1) before per‑token revocation is possible; otherwise you can only revoke whole user sessions.

Verification checklist

• Generate a token → confirm jti present.
• Store its jti in Redis with TTL = token expiry.
• Call protected endpoint → expect 200.
• Revoke the jti → call again → expect 401 Token revoked.
• Wait for token expiry → call again → expect 401 Token expired.