Building User Authentication

Sign-in, sessions, scopes, and gated pages for your app — the complete authentication system on a RUAL cluster.

Every RUAL cluster already has accounts, sign-in, sessions, and token management built in. Your job is to wire your app's pages and APIs to that system — not to build one. This tutorial assembles the full picture.

What the Cluster Handles for You

Deciding Who Can See What

Every page and API gets its audience from a scope:

Scope Who passes Use for
*publicAnyone, no tokenLanding pages, status endpoints, public content
*loggedinAny valid access_tokenMember areas, app pages, private APIs
Custom scope (e.g. billing_read)Users you granted that scopeRole-gated sections (admin, finance, support)

Set scopes per page block or API block via its lock icon — full mechanics in Remote Access Control. Grant custom scopes to users on their user detail page (custom_scopes) or bundle them in user groups — see User Roles Explained.

The Sign-In Flow

  1. A visitor hits a page scoped *loggedin without a token → the cluster serves the login page.
  2. They sign in (password, plus 2FA code when enabled) → the cluster issues an access_token and redirects back.
  3. The token travels as a cookie in the browser, or as a header/query param from your own frontend.
  4. Sign-out invalidates the token immediately; users manage their sessions on the default security page.

Building your own frontend? Call the sign-in API directly (POST /api/v1/auth/signin) and store the token — see the API workflows. For 2FA-enforced clusters, pass the current code from the user's authenticator.

Knowing Who's Calling

Inside any authenticated flow, the user_current block gives you the calling user's document: guid, name, scopes. Typical uses:

  • Filter data to the caller (owner_guid = user.guid in your queries — the denormalized owner pattern from Storages).
  • Branch on scope: allow admins to a management view, others to their own data.
  • Audit: write the actor onto every document you create.

Gating Pages and Sections

  1. Public marketing pages: scope *public.
  2. The app shell and member pages: scope *loggedin — unauthenticated visitors bounce to login automatically.
  3. Admin-only sections: a custom scope granted to admins only.
  4. Locked yourself out with a custom login page? Recover with ?studio=request — see Overwrite Default Pages.

Hardening Checklist

  • Enable 2FA for everyone who can reach Studio or admin scopes.
  • Keep *public for content that truly is public — check every page and API block once before launch.
  • Prefer custom scopes over checking usernames in flows.
  • Review the failed-login blocking and rate limits in Remote Access Control.
  • Audit access regularly on the User Activity page — see Auditing User Access.

Next Steps

Getting Access Accounts, first login, cluster URLs, and API tokens. Remote Access Control Scopes, rate limits, and throttling in depth. User Roles Explained Permissions, scopes, and user groups by role.