A team's JWT verifier reads the `alg` field from the token's own header to decide how to verify it. Why is that a real, historically exploited flaw, and what does pinning the expected algorithm in server-side configuration actually change about the verification process?

A JWT's header declares which algorithm was supposedly used to sign it — but that header is part of the token itself, which is attacker-controlled input, not a trusted instruction. A verifier that reads alg from the token and dispatches to whatever check that name asks for will, if it's naive, honour alg: none — a value the spec permits to mean "unsecured, no signature at all" — and accept a token with an empty signature segment whose claims an attacker edited freely. Pinning the expected algorithm in server-side configuration flips who decides: the verifier now knows, before it even looks at the token, exactly how a valid token must have been signed, and reads the token's own alg header for information only, never as an instruction about what check to run.