class

KemalIdentity::JWT::Algorithm

Inherits Reference < Object

A signature scheme a token may be verified with.

none cannot be expressed here

RFC 7519 defines an alg of none, meaning "this token is unsigned", and it is the single most reliably exploited flaw in JWT deployments: a library that honours it turns any token the attacker writes into a valid one. This shard has no way to say it. There is no None subclass, Validator refuses an allow-list containing "none" at boot, and the header's alg is checked against the key's algorithm besides — three independent places, because one place is one mistake away from none of them.

Verification, not signing

Only #verify is abstract. This shard validates tokens issued elsewhere — an identity provider, a gateway, another service — and minting them is deliberately out of scope, so there is no signing key to be careless with. ApiTokens::Service is what issues a credential here.

Adding an algorithm

Only HMAC is shipped, because Crystal's OpenSSL bindings expose HMAC and not the EVP interface that RSA and ECDSA verification need. RS256 and ES256 are therefore a subclass plus a C binding away rather than built in — implement #verify against whichever binding you already have. Everything else, kid selection included, is unchanged, since the keyring names the algorithm rather than trusting the token to.

Instance methods

name

The alg header value that selects this scheme, exactly as it appears in the token.

Source
verify(signing_input : String, signature : Bytes, key : Secret) : Bool

Whether signature is a valid signature over signing_input under key.

signing_input is the base64url header and payload joined by a dot, per RFC 7515 — the bytes as they arrived, never a re-encoding of the parsed claims. Re-encoding would mean verifying a signature over something the sender never signed.

Implementations must be constant-time and must not raise: everything here is attacker-supplied.

Source