Decoded is not verified: the JWT that trusts whatever the client wrote

1. The parse that skips the only step that mattered

The tell is a token being split on `.` and its middle segment base64-decoded and JSON-parsed to pull out a claim — a user ID, a tenant, a role. There is no call into a verification routine, no secret, no public key, no signature check. Frequently it's wrapped in a comment like "fall through if the secret isn't configured," which means: if verification can't run, use the claims anyway. That is a door with a lock that opens itself when the key is missing.

Once you accept an unverified payload, every claim in it is attacker-controlled. An attacker copies a real token's structure, changes `sub` to another user's ID or `role` to `admin`, re-encodes it, and sends it. Your code decodes it, reads the claim, and acts on it. The signature that would have rejected the tampered token was never consulted. You didn't authenticate anyone; you read a form the client filled out.

// Decoding. NOT verifying. Every field here is attacker-controlled.
const payloadB64 = token.split(".")[1];
const payload = JSON.parse(Buffer.from(payloadB64, "base64").toString());
if (payload.tenantId) return { tenantId: payload.tenantId }; // trusts a forgeable field

// Verifying: the signature is checked, or it throws.
import { jwtVerify } from "jose";
const { payload } = await jwtVerify(token, publicKey, {
  issuer: EXPECTED_ISSUER,
  audience: EXPECTED_AUDIENCE, // audience/issuer pinning closes token-replay across apps
});
return { tenantId: payload.tenantId as string }; // now it means something

2. Authenticated the token, authorized from a mutable field

The second variant verifies the token correctly and then makes the authorization decision from the wrong place. The token proves who the user is; the code then reads what the user is allowed to do from a profile document in a datastore — and if that document is writable by the user, or by anything the user can reach, the role is no longer a fact about them, it's a preference they can set.

Concretely: a login verifies a Firebase ID token, then fetches the user's role from a profile record and grants web-admin access based on it. If that profile store lacks tight write rules, elevating yourself is a matter of setting your own `role` field to `super_admin`. The authentication was sound; the authorization trusted a value the subject controls. Trust for authorization has to come from a source the subject cannot write — signed custom claims minted server-side, or a roles table only your backend can mutate.

3. Verify signatures, pin issuer and audience, source roles from server-writable state

Never hand-roll token parsing. Use the platform's verification library, give it the secret or public key, and let it check the signature, expiry, issuer, and audience — and let it throw. A verification failure is a rejected request, never a fall-through to trusting the claims. If the key isn't configured, the correct behaviour is to refuse to start, not to authenticate everyone.

Pin the issuer and audience explicitly. A signature check alone still accepts a validly-signed token minted for a different application in the same identity ecosystem; pinning `iss` and `aud` ensures the token was issued by who you expect, for you. And derive authorization from state only your server can write: signed custom claims for coarse roles, a backend-owned permissions table for anything finer. Re-check on sensitive actions rather than trusting a role snapshot taken at login, so a revoked privilege actually takes effect before the next dangerous operation.

Finally, lock down whatever profile store feeds identity. If a datastore document can influence who a user is or what they can do, its write rules are part of your auth system and must be as strict as everything else in it — the caller gets to write their preferences, never their permissions.