passwordoauthmagic link
jwtsigning secret{ "sub": "usr_8f2a", "role": "authenticated" }
hs256 · never shared across projects
Auth for your users, built in
Sign-up, sign-in, sessions and access control on every plan, signed with a secret that belongs to your project alone.
In practice
From your frontend, auth is two SDK calls. backend.auth.signUp({ email, password }) creates a real row in your project's users table, and backend.auth.signIn(...) starts a session the SDK carries on every request. Beyond email and password, projects can enable Google sign-in, email verification and magic links, with hosted pages and branded emails handled by the platform. The part you never see matters most: because sessions integrate with row-level security in PostgreSQL, a signed-in user's queries are already scoped to their own data. After every build Backenly proves it by signing in as a second test user and confirming they receive zero rows of another user's private data, with the evidence shown rather than asserted.
What it is
Every Backenly project includes a complete authentication system for the people who use your product. They register, sign in, and authenticate API requests with JWTs. It is isolated per project: each project has its own users table and its own signing secret, completely separate from every other project on the platform.
How it works
When a project is created, Backenly provisions a users table in the project's own schema, the sign-up and sign-in endpoints, token issuing and validation, and row-level security that scopes each user to their own data. Your frontend calls the endpoints directly or lets the SDK run the flows.
Why it matters
Authentication is one of the most security-critical parts of a backend, and one of the easiest to get subtly wrong. Backenly implements it correctly by default, with industry-standard JWTs, bcrypt password hashing and proper session handling, and then proves the isolation holds after every build.
What you get
Sign-up and sign-in endpoints
Every project gets its own sign-up and sign-in endpoints. Users register with email and password and receive tokens for their authenticated requests.
JWT sessions
Short-lived access tokens and longer-lived refresh tokens, signed with a project-specific secret that no other project shares.
Enforced by the database
Sessions integrate with row-level security, so a signed-in user reads and writes only their own rows, enforced in PostgreSQL rather than in API code.
SDK helpers
Sign-up, sign-in, sign-out and token refresh in the JavaScript SDK, so a frontend needs a few lines rather than an auth library.
Common questions
Yes. Authentication is included on every plan, Free included, with no auth-specific charges.
Auth settings are configured per project. Roles, permission policies and access rules can be set from the dashboard or by your agent.
Yes. Projects can enable Google sign-in for their users alongside email and password. Email verification and magic-link sign-in are also supported, with hosted pages and branded emails handled by the platform.
Related features
- Agent-built backendsTables, relations, APIs, auth and access rules, planned as typed actions, applied as one governed change and verified against the running backend.
- Postgres databaseDescribe the data model. Backenly creates the tables, relations, indexes and row-level security, in a schema that belongs to your project alone.
- REST APIEvery table is served by PostgREST, straight from the PostgreSQL catalog. Nothing to regenerate: a table created a second ago is queryable now.
Try it on a live project
One free project, no card. Connect your agent over MCP and read the verification evidence yourself.