How do you implement JWT authentication in NestJS with access and refresh tokens?

Q: How do you implement JWT authentication in NestJS with access and refresh tokens?

// JwtStrategy — validates Bearer token on protected routes @Injectable() export class JwtStrategy extends PassportStrategy(Strategy, 'jwt') { constructor(config: ConfigService) { super({ jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(), secretOrKey: config.get('JWT_ACCESS_SECRET'), ignoreExpiration: false, }); } async validate(payload: JwtPayload): Promise { return this.usersService.findOne(payload.sub); } } // AuthService — sign access and refresh tokens @Injectable() export class AuthService { async login(user: User) { const payload = { sub: user.id, email: user.email, roles: user.roles }; return { accessToken: this.jwt.sign(payload, { secret: this.config.get('JWT_ACCESS_SECRET'), expiresIn: '15m', }), refreshToken: this.jwt.sign({ sub: user.id }, { secret: this.config.get('JWT_REFRESH_SECRET'), expiresIn: '7d', }), }; } async refreshTokens(userId: number, refreshToken: string) { const user = await this.usersService.findOne(userId); const valid = await bcrypt.compare(refreshToken, user.hashedRefreshToken); if (!valid) throw new ForbiddenException('Invalid refresh token'); return this.login(user); } } Access tokens should be short-lived (15 minutes) — limits the window if a token is stolen. Refresh tokens should be long-lived (7 days) but stored hashed in the database. Use separate secrets for access and refresh tokens — a compromised refresh secret does not affect access verification. Never store plain refresh tokens — always hash with bcrypt before saving to the database. Validate refresh tokens by comparing the incoming token against the hashed version in the database.

Difficulty: 6/10

access token issuance, refresh token rotation, guard & strategy implementation

Create a JwtStrategy that validates the Bearer token from the Authorization header using the access token secret. In AuthService, sign separate access (short-lived) and refresh (long-lived) tokens with different secrets. Store a hashed refresh token in the database and verify it on the refresh endpoint.

JwtStrategy, token signing, and refresh endpoint

Access and refresh token design rules:

1
Access tokens should be short-lived (15 minutes) — limits the window if a token is stolen.
2
Refresh tokens should be long-lived (7 days) but stored hashed in the database.
3
Use separate secrets for access and refresh tokens — a compromised refresh secret does not affect access verification.
4
Never store plain refresh tokens — always hash with bcrypt before saving to the database.
5
Validate refresh tokens by comparing the incoming token against the hashed version in the database.

Scenario Questions

0-2 years experience

How do you implement JWT authentication in NestJS with access and refresh tokens?

Scenario Questions

Follow-up Questions