Security in SurrealDB: Best Practices Discussion 

Hi @martinomg, thank you for sharing your feedback! We are working hard on improving the security capabilities of SurrealDB. Fortunately, it seems that most of your requirements may already be met by the features available today. Although tokens do last 24 hours by default, the exact duration of scope tokens can be set via "DEFINE SCOPE" to any duration, including 15 minutes or just a few seconds using the "SESSION" clause. Additionally, any sessions established with a scope token gracefully expire when the token does, forcing the user (or any client acting on their behalf) to reauthenticate with credentials or a newer token before being able to perform authenticated actions. Although the connection is long lasting, the authenticated session lasts only for as long as you want it to last when defining the scope. Please see more info here: surrealdb.com/docs/surrealdb/surrealql/statements/define/scope When using JWT, frequently refreshed short-lived tokens are preferred over revocation, as such tokens are designed to be stateless. Since these tokens are stateless, they are not stored anywhere othen that the client and can be permanently destroyed by the user without any intervention from the backend application. Although I am not sure what you mean by "static" and "dynamic" in this context, I would say JWT are as "dynamic" as tokens get for this very reason. Since JWT are stateless by design, SurrealDB does not offer native capabilities to manage them statefully in the form of token management features. However, the "jti" claim was indeed added to all tokens issued by SurrealDB after this video was recorded in version "1.3.1". This claim allows developers to statefully track tokens issued and implement any additional token management logic in SurrealQL by accessing the JWT ID value via the "$token" parameter. In this way, you can implement token revocation for scope users with a "PERMISSIONS" clause by using a token revocation table. Although we cannot yet share specific plans about it, we are aware that some users do require stateful tokens (e.g. designed to be long-lived, audited, revoked...) and have some plans to tackle this use case soon.