class

KemalIdentity::JWT::HMAC

Inherits KemalIdentity::JWT::Algorithm < Reference < Object

HMAC over SHA-2: HS256, HS384 and HS512.

A symmetric scheme, so every party that can verify a token can also mint one. That is fine when the issuer and the verifier are the same deployment and the secret never leaves it, and it is the wrong choice for a token from a third party — there, an asymmetric algorithm is what stops your verifier's copy of the key from being a forging key.

Instance methods

minimum_key_bytes

Minimum key length in bytes, per RFC 7518 §3.2: "A key of the same size as the hash output or larger MUST be used". A 6-character HMAC secret is brute-forceable offline from a single captured token, so this is enforced rather than recommended.

Source

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