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.
Each workspace has its own sign-in page at emisar.dev/app/<workspace>/sign_in, and a
member signs in to each workspace separately. A member exists only inside its workspace,
with its own email address, MFA, and sessions. Someone who belongs to two workspaces is
two members and signs in to each.
Choose a sign-in method#
| Method | How it works | Use it when |
|---|---|---|
| A one-time link and a 6-character code go to the member's verified email address. Either works only in the browser that asked for it, and both expire in 15 minutes. | 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. The session opens only the workspace that owns the connection. | Your identity provider owns authentication and its MFA policy. Only available on Team & Enterprise. |
Sign-in codes are stored hashed. An intercepted email is not enough to sign in, because the browser that asked for it must finish the sign-in. Each code allows five tries. Sign-in is rate-limited by IP and email address, and failed attempts appear in the audit log. A browser stays signed in to at most six workspaces at once; signing out ends every workspace session in that browser. To connect an identity provider, continue with Single sign-on.
Enforce account sign-in#
- — Require MFA requires every session in this workspace to prove the member's current authenticator (TOTP). A member without one sets it up with any standard authenticator app before continuing; other sessions enter an authenticator or recovery code. Completing setup proves only that session, and disabling then re-enrolling invalidates earlier session proofs. Before emisar reveals an authenticator secret, the member proves the sign-in is still theirs. The proof is a code sent to their verified email address or, for a member who signs in only through single sign-on, a fresh sign-in at the identity provider. 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 makes members sign in through one of this workspace's SSO connections. Turning it on ends every email sign-in session in the workspace, and the sign-in page then offers only SSO. An invited person first confirms a code sent to the invited address, then signs in at the identity provider, which links that identity to their new membership.
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. Sign in to this workspace through SSO in another browser, keep that owner session open, and only then turn on Require SSO from Team → Security. Turning it on signs out every email sign-in session, including your own.
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. Use SCIM 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#
- — Profile lists your active sessions in this workspace with device information. You can sign out one session or every session except the current one after confirming. A session lasts at most 60 days. An administrator can suspend a member, which ends that member's sessions and revokes API keys issued from it. The person's members in other workspaces are not affected.
- — Disabling or deleting an SSO connection stops new sign-ins through it and ends the sessions that signed in through it. Email sign-in sessions remain. The connection lifecycle is in Single sign-on.
- — SCIM offboarding keeps the person: deactivation suspends access, while DELETE also retires the directory resource. The full lifecycle is in Directory sync.
Offboarding ends the member's sessions in this workspace and revokes every API key issued from it, including audit-export tokens. 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 request time first. If you are not sure identity is the cause, start at Troubleshooting. For a lockout with no working owner session, email support.