Single Sign-On (SSO)

Single Sign-On (SSO) lets your team log in to JAMS Incident Management via your existing identity provider. No JAMS Incident Management-specific passwords to manage; user offboarding in your IdP automatically revokes JAMS Incident Management access.

Plan availability: SSO is included on the Professional plan and up. Starter can add SSO as an add-on. See Plans & Billing.

JAMS Incident Management supports any OIDC-compliant identity provider — Microsoft Entra ID, Okta, Google Workspace, Auth0, OneLogin, Keycloak, AWS Cognito, Ping Identity, and many more. The setup is the same shape for all of them; only the IdP's portal looks different.

What you'll get

After setup:

Users hit /login, type their email, click Continue with [your IdP name]
They're redirected to your IdP, sign in there
They return to JAMS Incident Management already signed in — no password prompt

If you turn on Enforce SSO, JAMS Incident Management rejects password login entirely for everyone in your tenant. Useful for compliance ("all access goes through our IdP"). Optional — default is off.

Your tenant's /login page behaves differently depending on whether you've saved an SSO connection and whether Enforce SSO is on:

State	What you've done	What users see on `/login`
Password only	No SSO connection saved	The password field only — the original login flow, unchanged.
Hybrid (default after saving SSO)	SSO connection saved, Enforce SSO off	Both the password field and a "Continue with [your IdP name]" button. Users can use either.
SSO only	SSO connection saved, Enforce SSO on	The IdP button only. Password login is rejected for everyone in the tenant.

The hybrid state is the default the moment you save a connection. That's deliberate — it lets you test SSO end-to-end while password login still works as a safety net, so a misconfigured IdP can't lock anyone out. Only flip to SSO only once you've confirmed the IdP round-trip works (see the warning below).

Before you turn on Enforce SSO: make sure at least one admin can actually sign in via SSO. If every admin's IdP account is misconfigured and you also enforce SSO, nobody can reach the UI to turn it back off.

To de-risk this, JAMS Incident Management won't let you enable Enforce SSO until at least one SSO login has already succeeded for your tenant. If you try, the save is rejected: save with SSO optional first, complete one real SSO sign-in, then turn Enforce SSO on. You can also turn Enforce SSO back off at any time from /integrations/sso — it doesn't require operator help unless you're already fully locked out.

Important constraints (v1)

JAMS Incident Management's SSO is intentionally simple in v1. A few constraints to know:

No JIT provisioning. Users must already be invited to JAMS Incident Management (see Inviting Users) before they can sign in via SSO. SSO bypasses the password step but doesn't auto-create accounts. This prevents anyone with an @yourcompany.com email from creating their own JAMS Incident Management account without your invite.
One IdP per tenant. Pick the one your team uses. Multi-IdP support per tenant is a future feature.
OIDC only. SAML support is planned but not in v1. If your IdP only supports SAML (rare for new accounts), let us know.
Email-based matching. JAMS Incident Management matches the email returned by your IdP to the User record in JAMS Incident Management. They must match exactly. If your IdP returns Kevin.Casey@Example.com but JAMS Incident Management has kevin.casey@example.com, the case-insensitive match handles it — but anything else (typos, alias, different domain) will fail.

The shape of every IdP setup

Doesn't matter which IdP you use — the steps are always the same:

In your IdP, create an OIDC application (sometimes called "Web Application," "Regular Web App," etc.).
In your IdP, set the Redirect URI to whatever JAMS Incident Management's /integrations/sso page shows you. Format is https://<your-JAMS-backend-host>/auth/sso/callback — copy the exact value from the page rather than typing it.
In your IdP, copy three things: the Issuer URL (often called Discovery URL, OpenID Connect metadata URL — strip any /.well-known/openid-configuration suffix), the Client ID, and a Client Secret that you generate.
In JAMS Incident Management, open /integrations/sso and paste those three values into the form.
Save. Test by logging out and back in.
(Optional) Once you've confirmed SSO works for at least one admin, flip Enforce SSO on.

That's it. The differences between IdPs come down to where in their UI those four pieces of info live.

Detailed walkthroughs

If you use…	See this guide
Microsoft Entra ID (formerly Azure AD)	Entra ID setup
Okta	Okta setup
Google Workspace	Google Workspace setup
Auth0	Auth0 setup
Anything else OIDC-compliant	Use the Entra ID guide as a template — the JAMS Incident Management-side steps are identical; only the IdP-side UI differs.

After setup

The button label on /login uses the "Configuration name" you typed when saving the SSO config. So name it something users will recognize (e.g. "Microsoft Entra ID", not "config-1").
Existing users with passwords keep them. Turning on SSO doesn't delete anyone's password — they just stop using it. If you flip Enforce SSO off later, password login resumes for everyone.
Inviting users into an SSO-enforced tenant: invite as normal. JAMS Incident Management detects the enforced-SSO config and skips the password step on the invite accept page, sending the new user straight to your IdP after they fill in their name.

Troubleshooting

If SSO sign-in fails, the redirect from your IdP back to JAMS Incident Management includes a query param ?sso_error=<code> on /login. The error codes:

Error	What happened	Fix
`user_not_provisioned`	The email your IdP returned doesn't match any JAMS Incident Management User in this tenant	Invite the user from Team Members, then retry SSO
`account_disabled`	The user exists but is deactivated	Reactivate in Team Members
`sso_idp_rejected`	Your IdP refused the code exchange — usually a bad Client Secret	Re-save the Client Secret in /integrations/sso; generate a new one in your IdP if the old one was rotated
`sso_no_email_claim`	Your IdP didn't return an email in the ID token	Add `email` as a scope or optional claim in your IdP config
`sso_state_invalid`	The SSO session expired (5 min window)	Just retry — usually means the user left the IdP page open for too long

Security notes

Your Client Secret is encrypted at rest in JAMS Incident Management — AES-256-GCM with a key in Azure Key Vault. Never appears in API responses or logs.
The OAuth state is signed with JAMS Incident Management's JWT secret and includes PKCE, so even if an attacker observed the redirect URL they couldn't replay it.
Session JWTs are stored client-side in localStorage, same as password login. Same 8-hour expiry. Logout clears them.

What's next

Pick your IdP from the table above and follow the walkthrough. They're each about 10–15 minutes including the IdP-side configuration.