Short answer
In SurrealDB 1.0.0, session tokens are JWTs with a fixed-duration expiration, not an inactivity timeout. The default lifetime is approximately one hour, 3600 seconds, and it is configurable at server startup. There is no known difference between community and enterprise editions for this mechanism. Because 1.0.0 documentation is ambiguous, treat the specifics below as a working model to verify against your own instance.
Separating likely behavior from confirmed facts
Confirmed by design: authentication over WebSocket returns a JWT, and JWTs carry an exp claim. Expiration is time-based from issuance, not activity-based. An idle-but-connected subscription does not refresh the token, and an active one does not extend it.
Likely, pending verification:
- The default lifetime is 3600 seconds when no explicit value is set.
- Lifetime is set at startup via CLI flag or config, such as
jwt.expires_in / --auth-jwt-expires-in, and cannot be changed at runtime without restart.
- A server restart invalidates in-memory session state, so tokens may stop being accepted even before
exp.
- Community and enterprise editions share the same JWT machinery; no edition-specific default is documented.
Verification steps for your sandbox
- Start SurrealDB 1.0.0 via Docker with default settings.
- Connect over WebSocket, run
signin, and capture the returned token.
- Decode the JWT payload and read the
exp claim. Delta to now is effective lifetime.
- Keep a
live subscription open past expiry and observe auth rejection.
- Restart with an explicit expiry flag and confirm the
exp delta changes.
Practical implications
Plan for re-authentication. Detect auth failures on the socket, re-run signin, and re-issue live queries. If a reverse proxy terminates WebSocket, ensure its idle timeout exceeds token lifetime. Avoid very short lifetimes in production-like tests due to re-auth churn.
Missing detail that changes recommendation
The exact startup flags you use. If you already pass an auth/JWT expiry value, that value governs tokens, and verification from the exp claim confirms it directly.
surrealdb