How does a Bearer token carry user info?

Inside the token is a section that records who you are — for example a user identifier and a role. That section is encoded so anyone can decode and read it, and it serves as the starting point for pulling the user out in code.

Why isn't testing token-auth code with valid tokens alone enough?

With only valid tokens everything looks fine in normal use. A token is a value the user sends in themselves, so its contents can be altered — and only by feeding such a token do you find out how far the code is trusting it.

Why is the secret key (JWT_SECRET) needed?

For the receiving side to check "was this token really made by our server," it needs the secret key used to make it. The approach is to recompute the token's third piece with a secret key only the receiver knows, and match it.

Authenticate a User from a Login Token

Your task

There's a screen only logged-in users may use. Each request carries its token in the Authorization header as "Bearer <token>". Our auth guard has to pull the user out of that token and pass it along to the next step. Complete JwtAuthGuard.verify(token). The token is three pieces split by dots (.), and the middle piece holds the user info as { userId, role }. Pull userId and role out of it and return them; the guard then puts that onto req.user. The secret key lives in the environment variable JWT_SECRET. Note: if the token is missing or not in Bearer form, it's already blocked with a 401 (that part is higher up in the guard). Issuing (login), expiry, and refresh are out of scope for this task.

Ground rules

•Do not use a token library; use only Node's built-in tools.
•Read the secret key from the environment variable JWT_SECRET.
•Single instance, in-memory. No database.

Not required

•Login (issuing a token), expiry, refresh, logout.
•Role-based access control or permission branching.
•Password storage, sessions, cookies.

▶About this challenge

This challenge has you complete a NestJS auth guard. It pulls user info (userId, role) out of a token that arrives as "Bearer <token>" in the Authorization header, puts it on req.user, and blocks the request with a 401 when the token is missing. It uses no token library — only Node's built-in tools — and reads the secret key from the environment variable JWT_SECRET.

This problem is about "how far can you trust a token that came from outside." A token is a value the user carries in themselves, so if you trust its contents as-is you have no way to know who altered them. When verifying code like this, don't only check "does a valid token pass" — make a habit of checking "does a token with altered contents pass too." The real test is the moment a token that should not pass does.

How does a Bearer token carry user info?: Inside the token is a section that records who you are — for example a user identifier and a role. That section is encoded so anyone can decode and read it, and it serves as the starting point for pulling the user out in code.
Why isn't testing token-auth code with valid tokens alone enough?: With only valid tokens everything looks fine in normal use. A token is a value the user sends in themselves, so its contents can be altered — and only by feeding such a token do you find out how far the code is trusting it.
Why is the secret key (JWT_SECRET) needed?: For the receiving side to check "was this token really made by our server," it needs the secret key used to make it. The approach is to recompute the token's third piece with a secret key only the receiver knows, and match it.

Authenticate a User from a Login Token

Your task

Ground rules

•Do not use a token library; use only Node's built-in tools.
•Read the secret key from the environment variable JWT_SECRET.
•Single instance, in-memory. No database.

Not required

•Login (issuing a token), expiry, refresh, logout.
•Role-based access control or permission branching.
•Password storage, sessions, cookies.

▶About this challenge

How does a Bearer token carry user info?: Inside the token is a section that records who you are — for example a user identifier and a role. That section is encoded so anyone can decode and read it, and it serves as the starting point for pulling the user out in code.
Why isn't testing token-auth code with valid tokens alone enough?: With only valid tokens everything looks fine in normal use. A token is a value the user sends in themselves, so its contents can be altered — and only by feeding such a token do you find out how far the code is trusting it.
Why is the secret key (JWT_SECRET) needed?: For the receiving side to check "was this token really made by our server," it needs the secret key used to make it. The approach is to recompute the token's third piece with a secret key only the receiver knows, and match it.