Atlas SSO setup — point Atlas at your own IdP (OIDC)

Atlas supports three auth surfaces, which coexist: - OIDC login (this guide) — interactive humans log in via your own OpenID Connect IdP (e.g. Authentik). Atlas validates the id_token itself. - Forward-auth — the legacy/Seglamater model (a reverse proxy + Authentik outpost inject X-Authentik-* headers). Leave OIDC unset to keep using it. - Machine tokens (SEG-156) — automation uses Authorization: Bearer atlas_sk_… regardless of the human auth mode.

1. Register an application in your IdP

Create an OAuth2/OIDC provider + application (Authentik: Applications → Providers → OAuth2/OpenID): - Redirect URI: https://<your-atlas-host>/auth/callback (exact match). - Scopes: openid, email, profile, and a groups scope/mapping so the id_token carries a groups claim. - Note the issuer URL, client id, client secret.

2. Configure Atlas

Set per-deployment (env / .env; secrets belong in your vault, never in git):

ATLAS_OIDC_ISSUER_URL=https://auth.example.com/application/o/atlas/
ATLAS_OIDC_CLIENT_ID=...
ATLAS_OIDC_CLIENT_SECRET=...            # vault
ATLAS_OIDC_REDIRECT_URI=https://atlas.example.com/auth/callback
ATLAS_SESSION_SECRET=<random 32+ bytes> # vault; stable across restarts
# optional:
ATLAS_OIDC_SCOPES="openid email profile groups"
ATLAS_OIDC_GROUPS_CLAIM=groups
ATLAS_OIDC_ADMIN_EMAILS=you@example.com # bootstrap admins before the group exists

OIDC activates only when issuer + client_id + client_secret + redirect are all set.

3. Roles

Role comes from the id_token groups claim via the existing mapping: - members of ATLAS_GROUP_ADMIN (default atlas-admin) → admin (writes, customer-delete, token management). - everyone else authenticated → read-only.

Create those groups in your IdP and assign users. Before the group exists, list bootstrap admins in ATLAS_OIDC_ADMIN_EMAILS (only honored for IdP-verified emails).

The session cookie is Secure/__Host- only when Atlas knows the browser connection is HTTPS. Behind a TLS-terminating proxy it learns this from X-Forwarded-Proto, but only trusts that header from ATLAS_FORWARD_AUTH_TRUSTED_NETS. On an OIDC-only deployment behind a proxy whose network isn't in that list, set ATLAS_FORCE_SECURE_COOKIES=true so the admin-carrying session cookie always ships Secure (Fiona bd61de8f).

5. Log in

Send users to GET /auth/login → they authenticate at your IdP → back to Atlas with a session. POST /auth/logout clears it; GET /auth/me shows the resolved identity. /auth/login and /auth/callback are per-client rate-limited.

Security model (summary)

PKCE S256, single-use state + nonce, full id_token validation (JWKS signature — asymmetric algs only, iss/aud/azp/exp, nonce), email_verified-gated email linking, HMAC-signed session cookie (unforgeable without ATLAS_SESSION_SECRET). See Automation with machine tokens for the non-interactive auth surface and the API reference for the full endpoint list.