Every Auth feature is built from the same few parts. Learn them once and the rest of the section reads easily.

​
Users

A user is a person who can sign in to your app. Each user has: Users belong to an environment. A user in production does not exist in development, so test accounts never mix with real ones.

​
Identities

An identity is one way a user proves who they are: a password, a Google account, a company login. One user can have several, so the same person can sign in with a password today and Google tomorrow and end up in the same account. See Linked accounts.

​
Sessions

When someone signs in, Pawabase creates a session: one signed-in browser or device. A session consists of two tokens: The client library stores both, attaches the access token to requests and refreshes it quietly in the background. Your code never touches them. Two safety rules are built in:
  • A refresh token works once. Using it returns a new refresh token and invalidates the old one. If an old token is ever used again, Pawabase assumes it was stolen and ends the whole session. The auth webhook for this is session.reuse_detected.
  • The client shares one refresh between requests and, in browsers, between tabs, so normal use never trips this rule.
Lifetimes and the number of devices per person are settings. See Sessions.

​
What an access token says

The access token is a signed document that lists facts about the caller. Your access rules read these facts: Because the token is signed, the server trusts it without a database lookup. Because it is short-lived, a change you make (a new role, a disabled account) takes effect within minutes, or immediately if you end the person’s sessions.

​
Assurance levels

aal1 means the person proved one thing, like a password. aal2 means they also completed a second step. An access rule can require aal2 for sensitive actions, so a stolen password alone is not enough. See Two-step verification.

​
Keys: who is calling Pawabase

Separate from users, every request carries an API key that identifies your project:
  • A publishable key (pb_pk_…) goes in client code. On its own it can do only what your public rules allow; once a user signs in, requests are made as that user.
  • A secret key (pb_sk_…) belongs on a trusted server and bypasses all rules. Never ship it.
See Keys and security.

​
Putting it together

  1. Your app calls signInWithPassword.
  2. Pawabase checks the password against the user’s password identity, applies the lockout and device rules, and creates a session.
  3. The client stores the session and fires SIGNED_IN.
  4. Each later request carries the access token. Your rules see $auth.user_id, $auth.roles and the rest.
  5. Before 15 minutes pass, the client refreshes the token.
  6. signOut() ends the session on the server and forgets it locally.

Configuring Auth

Studio and code, side by side.

Sessions

Lifetimes, limits and revocation.