KemalIdentity::JWT::Key
One verification key, and the single algorithm it may be used with.
Why the key names the algorithm
Binding the two together is what defeats algorithm confusion, the second classic JWT
attack after alg: none. The attack: a service verifies RS256 tokens with a public
key, an attacker re-signs the payload as HS256 using that public key as an HMAC
secret, and a library that reads alg from the token and then asks "what key do I
have?" verifies it happily. The token got to choose how it would be checked.
Here it cannot. The keyring decides which key applies, the key states its algorithm,
and the token's alg header is only ever compared against that — it selects nothing.
Validator's allow-list is a second, independent gate on the same value.
Constructors
Instance methods
The kid this key answers to, or nil for a keyring holding exactly one key.
Not a secret and not a credential: it is a public label that says which key was
used, so publishing it in a token header costs nothing. Naming keys is what makes
rotation possible — see Keyring.
Redacted: a config dump in a crash report must not print a verification key, which
for HMAC is also a signing key and therefore forges tokens.
Redacted even for a public key, which is not itself a secret: the point is that no Key
ever prints its material, so nobody has to check which kind they are looking at.
Redacted: a config dump in a crash report must not print a verification key, which
for HMAC is also a signing key and therefore forges tokens.
Redacted even for a public key, which is not itself a secret: the point is that no Key
ever prints its material, so nobody has to check which kind they are looking at.