AUTH

Auth built into the database

Authentication and access control are part of the engine, not a service beside it. Define who can sign in and exactly what they can see - down to the row and the field - in SurrealQL, and enforce it inside the same transaction as the query.

Read the docs Start free with SurrealDB

01 |ACCESS CONTROL

Identity and permissions, defined in the query language

Sign-up and sign-in logic, token verification, and per-row rules all live in your schema - versioned with your data and enforced by the engine on every query.

DEFINE ACCESS account ON DATABASE TYPE RECORD
    SIGNIN (
        SELECT * FROM user WHERE email = $email
            AND crypto::argon2::compare(pass, $pass)
    );

-- After sign-in, $auth is the user's record, so table
-- permissions scope every query to it automatically:
SELECT * FROM order WHERE user = $auth.id;

RECORD ACCESS

Users authenticate against your own tables

DEFINE ACCESS turns SurrealDB into a web database: users sign up and sign in against the records you already have, with password hashing built in.

DEFINE ACCESS account ON DATABASE
    TYPE RECORD
    SIGNUP (
        CREATE user SET
            email = $email,
            pass = crypto::argon2::generate($pass)
    )
    SIGNIN (
        SELECT * FROM user WHERE
            email = $email AND
            crypto::argon2::compare(pass, $pass)
    );

ROW-LEVEL PERMISSIONS

Rules travel with the data

Permissions are declared on the table and enforced by the engine, so the same rule protects every query, live subscription, and API call - there is no application layer to forget it.

DEFINE TABLE order PERMISSIONS
    FOR select WHERE user = $auth.id
    FOR create WHERE $auth.id != NONE;

DEFINE TABLE post SCHEMALESS PERMISSIONS
    FOR select WHERE published = true OR user = $auth.id
    FOR create, update WHERE user = $auth.id
    FOR delete WHERE user = $auth.id OR $auth.admin = true;

FIELD-LEVEL CONTROL

Validate and constrain every field

Type, assert, and default each field in the schema. Constraints run on write, so bad or unauthorised data never lands.

DEFINE FIELD email ON TABLE user
    TYPE string
    ASSERT string::is_email($value);

DEFINE INDEX email ON TABLE user
    FIELDS email UNIQUE;

Everything an auth layer needs, in the engine

Sign-in methods, token verification, and access scopes are first-class database objects - defined once and enforced everywhere.

Record access

Sign users up and in against your own tables, with flexible rules and built-in password hashing.

Learn more

JWT and third-party

Verify tokens from Auth0, Clerk, or any provider across the RS, ES, PS, and HS algorithm families.

Learn more

System users and scopes

Root, namespace, and database users with role-based access, scoped to exactly the resources they need.

Learn more

Row and field permissions

PERMISSIONS clauses on tables and fields enforce access on every read and write, inside the transaction.

Learn more

Encryption and TLS

Encryption at rest with standard algorithms and end-to-end TLS in transit, configurable per deployment.

Learn more

Multi-tenant isolation

Namespaces and databases isolate tenants completely, so one permission model serves every customer.

Learn more

02 |ONE ENGINE

No separate auth service to run

Bolt-on auth means a second system to deploy, a second place for rules to drift, and a network hop on every check. In SurrealDB, identity and permissions are evaluated where the data lives.