Should a JWT key be written into a SurrealDB DEFINE ACCESS?
JWT signing secret in the migration
Critical: SurrealDB refuses the migration, loses data, or leaks a credential.
What happens
DEFINE ACCESS ... ALGORITHM HS256 / HS384 / HS512 KEY '...', a WITH ISSUER KEY, and the removed DEFINE TOKEN ... VALUE put a signing secret in the file. Anyone who can read the repository can mint tokens the database accepts, as any record user the access method covers.
Why it is dangerous on a populated table
Table size does not change this one: a signing key committed to the repository lets anyone who reads it mint accepted tokens, and git history keeps it after the fix.
Fires on
DEFINE ACCESS api ON DATABASE TYPE JWT ALGORITHM HS512 KEY 'k3y-that-signs-everything';The safe pattern
Verify tokens with a JWKS URL, or with an asymmetric algorithm (RS, ES, PS, EdDSA) where the migration carries only the public key. Keep issuer keys in the deploy environment.
DEFINE ACCESS api ON DATABASE TYPE JWT URL 'https://auth.example.com/.well-known/jwks.json';Fixtures
The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.
Fires (3)
DEFINE ACCESS account ON DATABASE TYPE RECORD SIGNIN (SELECT * FROM user WHERE email = $email) WITH JWT ALGORITHM RS256 KEY '-----BEGIN PUBLIC KEY-----MIIBIjAN' WITH ISSUER KEY '-----BEGIN PRIVATE KEY-----MIIEvQIB';DEFINE ACCESS api ON DATABASE TYPE JWT ALGORITHM HS512 KEY 'k3y-that-signs-everything';DEFINE TOKEN legacy ON DATABASE TYPE HS256 VALUE 'shared-secret';Stays silent (2)
DEFINE ACCESS api ON DATABASE TYPE JWT URL 'https://auth.example.com/.well-known/jwks.json';DEFINE ACCESS api ON DATABASE TYPE JWT ALGORITHM RS256 KEY '-----BEGIN PUBLIC KEY-----MIIBIjAN';How to check locally
SurrealDB support is in beta: this rule runs locally in the free CLI over .surql migrations, static only, and not in the hosted service yet. No install, nothing leaves your machine:
npx bolvrk check migration.surql --engine=surrealdb