Single sign-on (SSO)

mngd supports two standard SSO protocols for admin portal login:

• OpenID Connect (OIDC) — any IdP that exposes .well-known/openid-configuration (Okta, Azure AD / Entra ID, Google Workspace, Auth0, Keycloak, Authentik, etc.).
• SAML 2.0 — any IdP that publishes metadata (Okta, Azure AD, Google Workspace, OneLogin, ADFS, etc.).

Both are generic — mngd doesn’t ship vendor-specific connectors. Paste your IdP’s issuer URL / metadata and mngd takes it from there.

Setting up an SSO connection

Go to Settings → Identity. The Single Sign-On section has two buttons: Add SAML connection and Add OIDC connection.

OIDC

You’ll need:

• Issuer URL — e.g. https://yourtenant.okta.com, https://login.microsoftonline.com/<tenant-id>/v2.0, https://accounts.google.com.
• Client ID and Client secret from an application you create in the IdP. Scopes required: openid, email, profile (all added by default).

The redirect / callback URL to register in your IdP is:

https://app.mngd.app/api/v1/auth/oidc/{connID}/callback

mngd shows the exact URL with the generated connection ID after you save the connection.

mngd validates the issuer at save time by fetching .well-known/openid-configuration — the endpoint has to be reachable from mngd’s servers, not just from your laptop.

SAML 2.0

You’ll need your IdP’s metadata. Two options:

• Metadata URL — paste the URL and mngd fetches + parses it.
• Metadata XML — paste the full XML directly. Use this when the metadata URL isn’t publicly reachable.

After save, mngd shows two SP-side URLs to register in your IdP:

SP Entity ID:   https://app.mngd.app/api/v1/auth/saml/sp
ACS URL:        https://app.mngd.app/api/v1/auth/saml/{connID}/acs

NameID format: email. Signed assertions are required — mngd rejects unsigned assertions.

How users sign in

The mngd login page lists all active SSO connections as named buttons. A user clicks the one that matches their org’s IdP.

• OIDC: browser redirects to your IdP’s authorize endpoint with PKCE, user authenticates, IdP redirects back with an auth code, mngd exchanges it for tokens and issues an mngd session.
• SAML: SP-initiated — mngd builds an AuthnRequest, user lands on your IdP, IdP posts the signed assertion to the ACS URL, mngd creates the session.

There is no email-domain autodiscovery yet. If you want to hide the standard password / magic-link login and require SSO, see Setting → Identity → Authentication policy → Require SSO.

JIT provisioning

On first SSO login, if a user doesn’t already exist in your org, mngd auto-creates them with the viewer role. Admins promote specific users via Settings → Admins or via SCIM group mappings (see below).

If a user already exists by email, the SSO identity is attached to that account on first SSO login — their existing role and permissions are preserved.

Role mapping from SSO claims

Role mapping at SSO login is not currently supported. mngd reads:

Protocol	External ID	Email	Display name
OIDC	sub claim	email claim	name claim
SAML	NameID	email attribute	displayName attribute

Group / role claims (groups, roles) are ignored at sign-in time. To map IdP groups to mngd roles, use SCIM group mappings — see the SCIM guide. The IdP pushes group membership via SCIM, and mngd applies the mapped role on group join.

If SSO is configured without SCIM, new users get the default viewer role and admins have to promote them manually.

Session behaviour

A successful SSO login issues a mngd session token (PASETO v4, symmetric). Token properties:

• Sent back as an opaque bearer token — your browser stores it in the authed app’s memory + HTTP header; it’s not a JWT and can’t be inspected client-side.
• TTL is set per-org under Settings → Identity → Session security. Default is 30 days.
• Session rows are tracked server-side (IP, user-agent, fingerprint). Admins can revoke individual sessions or Revoke all sessions (owner-only) for incident response.

Removing or disabling a connection

From Settings → Identity, click the connection and choose Disable (stops new logins, keeps the history) or Delete (removes the connection and the login buttons). Existing sessions for users who signed in via that connection remain valid until they expire or are explicitly revoked.

What this doesn’t cover yet

• Domain-bound SSO — a user with @acme.com going straight to their org’s IdP without seeing the connection list. Not yet implemented; listed on the roadmap.
• Enrollment SSO for OIDC — MDM / agent enrollment that requires users to sign in via SSO first. Shipped for SAML only; OIDC enrollment SSO is in flight.
• Custom claim → attribute mapping — attribute_map exists in the DB schema but isn’t actively processed. The claim list above is the full set read at login.