How Atlas works

Atlas sits between your users and your application code as a dedicated identity layer. Understanding the four moving parts makes everything else in this guide click.

The four parts

1. Your frontend

Your web or mobile UI runs the sign-in experience — hosted pages, the embed widget, or the SDK. It authenticates to the Frontend API with a publishable key (pk_…), which is safe to ship publicly. The frontend never handles passwords or provider secrets directly; it only advances an authentication attempt.

2. The Atlas instance

The heart of the system. Each instance holds your users, sessions, organizations, roles, connections, MFA factors, webhooks and audit log — all isolated per tenant. You get a Development and a Production instance per application, and they never share data.

3. Your backend

Your servers authenticate to the Backend API with a secret key (sk_…) to read and manage users, organizations and sessions. Your backend also verifies the session tokens users carry.

4. The public JWKS

Atlas publishes a signed set of public keys at /.well-known/jwks.json. Any service you run can use it to verify a session JWT offline, with no round-trip to Atlas.

A request, end to end

1. A user opens your app and clicks Sign in.

2. The frontend (with pk_…) starts an attempt against the Frontend API.

3. Atlas runs the flow — identifier, factor, optional MFA — and issues a session.

4. The session (a signed JWT) is set on your domain and travels with each request.

5. Your backend verifies the JWT against the JWKS, or calls the Backend API with sk_….

6. Authorization checks (roles, permissions) decide what the user may do.

Why this shape matters

• Secrets stay server-side. The browser only ever holds a publishable key.

• Verification is cheap. Stateless JWT checks against JWKS mean no bottleneck.

• Tenancy is enforced at the core, not bolted on — see Organizations & teams.

Next

Learn how Development and Production instances differ → Instances & environments.