RFC 7518 registers dozens of algorithms. Most of the time you need one, and picking it takes three questions.
Question one: who verifies?
If the same party issues and verifies, a shared secret is enough: HS256. It is fast and simple.
If somebody else verifies, you need asymmetric signing, so they hold only a public key. ES256 gives short signatures and fast verification. EdDSA is the modern choice where support allows. RS256 remains the safest bet for interoperability, at the cost of much larger signatures.
The failure to avoid: issuing with HS256 and letting anyone with the shared secret mint tokens you will accept. A shared secret is a signing key handed to every verifier.
Question two: how long does the token live?
A short-lived access token and a long-lived assertion do not warrant the same choices. The longer a token stays valid, the longer a compromised key stays useful, and the more rotation discipline matters.
Question three: are you encrypting?
For key management, prefer ECDH-ES or RSA-OAEP-256. For content, A256GCM.
Names to stop using
none. Not an algorithm, an absence of one. Never on the verification side.RSA1_5. RSAES-PKCS1-v1_5, whose padding has been a source of oracles for twenty-five years. Even a correct implementation needs care.PBES2-*with an attacker-controlled iteration count. One number in a header can pin a CPU.
The rule that outranks all of this
Whatever you choose, decide it on the verifying side and refuse everything else. A verifier that accepts whatever algorithm the token declares is a verifier an attacker configures.