Skip to main content

Identity Providers

Atrium supports two authentication approaches: a built-in identity provider and external OIDC-compliant identity providers. You can use either one — the choice is per tenant.

Built-in identity provider​

The built-in IdP is Atrium's default authentication system. It handles email/password authentication directly, with no external dependencies.

When to use the built-in IdP:

  • Your organization doesn't have an enterprise identity provider.
  • You're running a self-hosted deployment and want zero external authentication dependencies.
  • You're in a pilot or evaluation phase and want to get started quickly.
  • You have a small team and don't need centralized identity management.

Features:

  • Email/password authentication with argon2id password hashing.
  • Optional TOTP-based multi-factor authentication (time-based one-time passwords via apps like Google Authenticator, Authy, or 1Password).
  • Admin-initiated user creation (no self-registration).
  • Password reset with must-change-password enforcement.

The built-in IdP stores credentials in Atrium's own database. In self-hosted deployments, all authentication data stays on your infrastructure.

External OIDC providers​

For organizations with an existing identity provider, Atrium integrates via OpenID Connect (OIDC). Your IdP handles the authentication; Atrium trusts the identity it provides.

Supported providers​

Any OIDC-compliant identity provider works. Specifically tested and documented:

  • Microsoft Entra ID (formerly Azure AD) — The most common enterprise IdP.
  • Okta — Popular in mid-market and enterprise.
  • Google Workspace — For organizations using Google as their identity provider.
  • Keycloak — Open-source IdP, common in self-hosted environments.

How it works​

  1. The Tenant-Admin configures the OIDC provider in Atrium's settings: issuer URL, client ID, and client secret.
  2. When a user logs in, Atrium redirects them to the IdP's login page.
  3. After successful authentication, the IdP sends back an ID token.
  4. Atrium validates the token against the IdP's JWKS endpoint and creates a platform session.

From this point on, all authorization is handled by Atrium's own JWT tokens. The platform controls what the user can do (role, site assignments) — the IdP only establishes who they are.

Key characteristics​

  • Session independence: Atrium issues its own session tokens (15-minute access token, 7-day refresh token). If your IdP goes down temporarily, users with active sessions can continue working.
  • Authorization is Atrium-side: The IdP authenticates identity. Roles and site assignments are configured in Atrium, not imported from the IdP. This means a user logging in via Entra ID still needs a matching user record in Atrium with a role and site assignment.
  • No auto-provisioning: Users must be created in Atrium before they can log in via OIDC. The IdP login will fail if there's no matching Atrium user record for the authenticated email address.

Configuration​

To configure an external OIDC provider:

  1. Register Atrium as an application in your IdP (Entra ID App Registration, Okta Application, etc.).
  2. Note the Client ID, Client Secret, and Issuer URL (also called "Authority" or "OpenID Configuration URL").
  3. In Atrium, navigate to Settings → Identity Provider.
  4. Enter the OIDC configuration details.
  5. Save and test with a user account that exists in both the IdP and Atrium.

Detailed setup guides for each provider:

Switching between providers​

A tenant can switch from the built-in IdP to an external OIDC provider (or vice versa). When switching:

  • Users must have matching email addresses in both systems.
  • Passwords stored in the built-in IdP are not migrated to the external provider (and vice versa).
  • Active sessions continue until they expire — no forced logout.

Self-hosted considerations​

In self-hosted deployments:

  • The built-in IdP is always available — it requires no external connectivity.
  • External OIDC requires that the Atrium server can reach your IdP's endpoints (JWKS, authorization, token). If the IdP is hosted externally (e.g., Entra ID, Okta), the server needs outbound HTTPS access to those URLs.
  • If your IdP is hosted on your own network (e.g., Keycloak, ADFS), ensure the Atrium server container can resolve and reach it.