Docs navigation
Get started
AI agents
Connect
Operate
Day to day
When it breaks
Govern access
Team & account
Access
Identity concepts
Provider guides
Account
Authentication
Choose how people sign in, how the account enforces that choice, and whether your directory or an emisar administrator owns the member lifecycle.
Choose a sign-in method#
| Method | How it works | Use it when |
|---|---|---|
| Magic link | A single-use, expiring code goes to the member's email, paired with a nonce held by the browser that started the sign-in. | You do not need organization-managed sign-in, or you are testing account access before enforcing SSO. |
| OIDC SSO | emisar redirects the member to your identity provider to sign in, and matches the returning identity by the provider's stable subject, never by email. | Your identity provider owns authentication and its MFA policy. Only available on Team & Enterprise. |
Magic-link codes are stored hashed, and an intercepted email is not enough to sign in — the browser nonce is required. Sign-in is rate-limited by IP and email address, and failed attempts appear in the audit log. To connect an identity provider, continue with Single sign-on.
Enforce account sign-in#
- — Require MFA requires this browser to prove the member's current TOTP enrollment before they can use the account. Members without TOTP set it up with any standard authenticator app; other unproved sessions enter an authenticator or recovery code. Completing setup proves only that browser, and disabling then re-enrolling invalidates earlier session proofs. Before emisar reveals an authenticator secret, the member confirms a code sent to their current email address — a provider that supplies no email leaves enrollment closed until an administrator corrects the identity. An SSO connection satisfies the requirement only when you mark that provider as enforcing MFA; otherwise emisar still asks for TOTP. Recovery codes are shown once and each works once. Regenerating a new set requires a current authenticator or recovery code; the old set works until the new one is issued.
- — Require SSO accepts only an SSO identity issued for this account; a member who signed in with a magic link is sent to your provider on their next page load.
Require SSO governs browser sign-in — the console, the audit CSV download, and the OAuth consent screen — for every member, owners included, with no bypass. It does not authenticate MCP bearer tokens, SCIM, or the audit export API. Turning it on does not revoke existing API keys or OAuth grants — revoke those through Rotate and revoke credentials. It applies only while at least one provider stays enabled, and a broken provider does not open the gate: sign-in fails until it works.
Save the connection, then choose Verify sign-in to complete a real provider sign-in. Keep an owner session open while you check it, and only then turn on Require SSO from Team → Security.
Provision and remove members#
Pick one system to own the member lifecycle. Sign-in and lifecycle are separate protocols: OIDC authenticates a person, and SCIM creates, updates, suspends, and groups that person.
- — Invitations let an owner or admin create the membership and choose its role before the person signs in.
- — SSO auto-provisioning creates a member on first successful sign-in at the connection's default role and runner access. Manual approval holds that first sign-in for an administrator instead.
- — SCIM directory sync provisions the membership before first login, applies group mappings, and suspends it when the directory marks the user inactive. SCIM is the path when offboarding in your IdP must revoke emisar access automatically.
Teams & access owns roles, runner scopes, invitations, and manual suspension. The SCIM guide owns the directory lifecycle and protocol contract.
Provider support#
| Provider | Directory sync |
|---|---|
| Okta | Separate SCIM application |
| Microsoft Entra | Separate enterprise application |
| JumpCloud | Same custom application |
| Google Workspace | No outbound SCIM for a custom app |
| Keycloak | Needs a third-party outbound SCIM client |
| Generic OpenID Connect | Any client that implements the documented SCIM subset |
Sessions and offboarding#
- — Members manage their own sessions from Profile — it lists each active session with device information. They can sign out one session or every session except the current one after confirming. An administrator can suspend a membership, which ends its sessions and revokes API keys minted from it.
- — Disabling or deleting an SSO connection ends the sessions it authenticated — the connection lifecycle is in Single sign-on.
- — SCIM offboarding preserves the person: deactivation suspends access, while DELETE also retires the directory resource. The full lifecycle is in Directory sync.
Offboarding a person ends what their membership issued: sessions, and every API key they minted — audit-export tokens included. Enrollment keys, SCIM bearers, signing keys, and keys held by other members keep working — rotate or revoke those through Rotate and revoke credentials. During an incident, follow Security incidents to preserve evidence.
Troubleshooting#
When sign-in fails, start with the symptom table in SSO troubleshooting; when provisioning or group access is stale, use SCIM troubleshooting and check the connection's Last sync first. If you are not sure identity is the cause, start at Troubleshooting. For a lockout with no working owner session, email support.