Again, the library can provide that functionality in a better way. In this case, the library could provide a means for the consuming code to be queried about what keys are available. E.g., in JS-like pseudo-code:

  validator = new JwtValidator();
  // By default, the validator should reject everything, until you call…
  validator.add_signing_key(new RsaSigned((a strongly-typed RSA key));
  // I wouldn't even add this to the library, but let's
  // say you want to comply with the RFC fully:
  validator.add_signing_key(new CompletelyUnsafeNoneAlgorithm());
  // (And I'd name it that explicitly, to let the consumer know that
  // what they're doing is nuts.)

This validator knows exactly which algorithms — and keys — are valid.

If the full keyset is somehow not known ahead of time, a callback to enumerate keys of a certain type could be configured.

Better API design here prevents this vuln. from ever happening.

(Personally, I wish the RFC had never added "alg": "none"; it's a mistake waiting to happen. I wish JWS/JWT could be updated to remove it.)