Why can accepting any algorithm declared by a JWT be dangerous?

The token header is supplied by whoever created it, so an attacker can put any value there. If the verifier trusts it, classic attacks work: a token claiming no signature, or an asymmetric public key being used as a shared secret. The verifier should decide from its own configuration which algorithms and which key belong to the issuer, accept only that allowlist, and reject everything else. Use a maintained library and validate issuer, audience and expiry as well. Never let the token pick the rules used to check itself.

What the interviewer is assessing

Whether you know the verifier, not the token, must control the algorithm and key used for validation.

A strong answer covers

• Whoever creates the token writes its header, so an attacker can put any algorithm there; it cannot be trusted.
• The verifier uses its own configuration to decide which algorithms and key belong to the issuer, accepts only an allowlist and rejects everything else.
• Know the classic attacks: a token claiming no signature, or an asymmetric public key being used as a shared secret.
• Beyond the signature, also validate issuer, audience and expiry claims.
• Rely on a maintained, well-tested library rather than writing verification yourself.

Common mistakes

• Reads the algorithm from the header and passes it straight to the library.
• Checks the signature but skips issuer, audience and expiry validation.

Practise a follow-up

• How would you handle key rotation?
• Why is the none algorithm dangerous?