Skip to main content

Users and authentication security and limits

TaruviBase has two kinds of access: organization access, which lets your team manage sites in Console, and site access, which lets people use your app.

Scope and mutations#

Cloud users, organization memberships, invitations, and site-access synchronization are Console-only.

Any signed-in user of a site can list and read its site users. Creating, updating, and deleting site users needs organization access or a Super Admin app role in one of the site's apps; anyone else gets 403 FORBIDDEN. Only a superuser can change a superuser, and a Super Admin app role can't change members of your organization. Assigning roles and changing the user-attribute schema need organization access. See Who can manage users.

User deletion is a soft delete, and a user can't delete itself; follow the site user deletion controls. Deleted users can't be restored through the Console or API; if you need a user restored, contact TaruviBase support.

API tokens#

Only organization owners, admins, and members can create API tokens; a site user gets 403. A token acts as its creator, so requests made with it have organization access: they skip app roles and Database row policies, and policy checks allow every action. Use tokens for trusted server jobs, and forward a user's session token to act for that user. Tokens have no independent per-token scope. Treat plaintext token output as one-time secret material and prefer a finite expiry. Revoking a token returns 200 OK.

If one-time plaintext is lost, create a replacement, store it immediately, update and test consumers, then revoke the old token when possible. See API tokens.

Hosted flow and SSO#

Hosted sign-up is controlled by security.signup-enabled. Two-factor authentication isn't available yet; the Enable 2FA security setting currently has no effect. OpenID Connect provider records are shared rather than site-isolated; deletion is blocked while connected users exist.

Use hosted sign-in for session recovery and OpenID Connect SSO for shared-provider deletion controls.

Good practices#

  • Create a site user for each person who uses your application; a cloud user or organization membership doesn't replace one.
  • Keep credentials, private identity data, and secrets out of URLs, screenshots, and logs.
  • A token always acts with its user's current permissions, so changing a user's access changes what their tokens can do.