JWT claims

The token bento login stores — and the one you mint in the dashboard — is an Ed25519-signed JWT. The CAS worker at cache.bento.build verifies it against the public keyset at https://api.bento.build/.well-known/jwks.json; the private half never leaves the control plane.

The claim shape is defined in the OSS bento-cas-protocol crate, which both sides depend on, so client and server can’t drift.

Header

Field	Value
alg	EdDSA (Ed25519)
kid	Signing-key id. Selects the verify key from JWKS, so keys can rotate without invalidating live tokens.

Payload

Claim	Type	Meaning
iss	string	Always bento.build for the hosted service.
org_id	string	Org the token ultimately belongs to — the tier and quota boundary. The worker checks this before allowing writes.
team_id	string	Team the token grants access to. Also the cache’s key partition: a token can only ever read and write its own team’s entries.
scope	string	read, read_write, or admin. See Tokens › Scopes.
label	string	The audit label you supplied at mint time.
iat	number	Issued-at, seconds since the UNIX epoch.
exp	number	Expiry, seconds since the UNIX epoch. Bounds the damage from a leaked token regardless of revocation.
jti	string	The token’s own id. What revocation lists.
revocation_required	bool	Whether the worker must treat the revocation lookup as load-bearing. true for admin scope or a TTL over 7 days — on a lookup error those fail closed. false skips the lookup on the hot path, appropriate when exp is already short.

Reading your own

bento doctor --cloud

prints iss, team_id, scope, and label from the token currently in scope, plus its remaining lifetime. It decodes the payload for display and does not verify the signature — that happens at the edge, on every request.