Reform published a walkthrough of JWT and RBAC in APIs that gets the distinction right in one line: “JWT proves identity, RBAC controls access, and short-lived tokens limit stale access risk.” The detail holds up. RS256 with keys published as a JWKS per RFC 7517. The standard claims — sub, iss, aud, exp, nbf — separated from the custom ones a system actually branches on, roles and tenant_id. A five-to-fifteen-minute token lifetime, justified rather than asserted, because “AuthN verifies the token. AuthZ checks those claims against the endpoint rule” and the claims went stale the moment they were signed. Best of all is the framing they lead with: “treat the JWT as a snapshot of access at login time.” That single sentence explains more about why authorization drifts than most security documentation manages in a page, and the accompanying insistence that 401 and 403 are different answers is the same discipline other providers have needed telling twice this month.
It is a generic tutorial. It documents nobody’s API in particular, and certainly not Reform’s — the examples reach for .NET’s HttpContext.User and Spring Security rather than anything the company operates. That is worth noting without scolding, because the interesting version of this post was available to them and is one they are uniquely placed to write.
The catalog reads Reform as a single API page, Reform Forms, and the record is explicit about the shape of the company: no REST API, no SDK, no OpenAPI definition. The integration surface is three published pieces — a signed outbound webhook carrying form.submitted with an HMAC-SHA256 signature, a CDN-hosted browser embed with a parent-page event API, and a headless mode where you post your own HTML form using answers[block-id] field naming. There is no bearer token in that architecture and nothing for a role to gate. The auth problem Reform actually has is webhook signature verification, which is where integrators reliably go wrong: comparing signatures without a timing-safe compare, skipping the replay window, never rotating the secret.
Reform scores 49.8, developing on the Kin Score, and the standout facet is access clarity at 89.5 — near the top of the catalog — against operational transparency at 7.9. Agent Readiness is 22.3, agent-aware, with auth_clarity and event_surface_described both lit. Read those together and the catalog is paying Reform a compliment that the blog post talks past: for a company with three integration points and no REST API, they have documented what they do have unusually clearly, and the signing and the event are both legible. The gap here is not rigor, it is subject. A thousand competent JWT tutorials exist. One good explanation of how to verify Reform’s HMAC signature, from Reform, would be the only one.