Authentication
Users, sign-in methods and passwords in each realm.
Each realm with auth: enabled has its own pool of users and API keys, stored in the realm’s system database. One sign-in is meant to work across all databases of that realm (single sign-on), and never in another realm.
What’s available
| Feature | Status |
|---|---|
Users and passwords, managed with backd user or the admin API | available |
Command-line administration: backd bootstrap, backd login | available |
Sign-up, login and sessions (/v1/{realm}/_auth/…) | available |
| API keys for server-side services, with full access to the realm’s data | available |
Access rules per collection (rules: in collection.yaml) | available |
| Admin API for server-side user management | available |
| Audit trail of security-sensitive actions | available |
| Deactivating and erasing users, with per-collection policies for their data | available |
See the security model for what backd protects, and the hardening checklist before exposing a realm.
| Brute-force protection on login | available |
Users and sign-in methods
A user holds only identity data: a unique email, whether that email is verified, roles, and whether the account is disabled. Credentials are not part of the user. Each way of signing in is a separate sign-in method (an identity) linked to the user:
- today there is one kind, password;
- sign-in with external providers (Microsoft, Google, Apple, …) is planned. It will add new kinds of sign-in methods to existing users without changing how users are stored.
So a user can exist without a password, for example when an operator creates the account first and sets the password later.
Application data about a user, such as a display name or avatar, belongs in your own collections, not in the user.
Create a realm’s first administrator with backd bootstrap, then manage users and API keys from the command line through the admin API.
Users and passwordsCreate and manage a realm’s users with backd user or the admin API.
Sign-up, login and sessionsThe /_auth endpoints: sign up, log in, manage sessions, change or delete the account.
API keysGive server-side services access to a realm’s data with API keys.
Access rules (rules:)Decide per collection which callers may read, create, update and delete documents.
Admin APIManage a realm’s users and roles from server-side services with an API key.
Admin UIThe web interface for operating a realm: switching it on, who sees what, and where to serve it.
Audit trailA permanent, append-only record of who changed users, roles, network restrictions, API keys and invitations, and when.
Deleting and erasing usersDeactivate an account and keep its data, or erase a user: a tombstone, and the collections’ policies applied. What is kept, and for how long.
Security modelWhat backd protects, how, and a checklist before exposing it.