Flamekeeper supports company sign-in through Okta and Microsoft Entra ID. Organization administrators configure the connection in Organization settings. This helps teams fit handover documentation into their existing company sign-in process, with the identity provider's authentication policies applied to SSO.
Choose your setup guide
- Connect Okta: create an OIDC application, find the issuer and credentials, and enable the connection.
- Connect Microsoft Entra ID: register an application, copy the tenant and application IDs, create a secret, and connect it to Flamekeeper.
- Automatically deactivate users with SCIM: connect application assignments to Flamekeeper so removed users lose access.
Both guides include DNS ownership verification and a first-login check. You will need an administrator in your identity provider and someone who can add a DNS TXT record for your email domain.
What SSO changes
Once the domain is verified and SSO is enabled, entering a matching email on the Flamekeeper login page starts company sign-in. Matching uses one exact domain: example.com does not include team.example.com.
Members must already belong to your organization, have verified their Flamekeeper email, and have an active or departing status. SSO does not create accounts, accept invitations, synchronize groups, or change Flamekeeper roles. Use People and invitations to manage membership first.
Password login remains available. This is optional company sign-in, not an SSO-only policy. By default, removing an identity-provider assignment does not disable the Flamekeeper account. An Admin can enable SCIM deprovisioning to automatically deactivate matching members and revoke their Flamekeeper access when they are removed from the provider application.
Switching providers
Only one provider can be configured per organization. Saving a configuration in the other provider's tab replaces the current connection and starts the replacement disabled. Enter the new provider's credentials, review the summary, and enable it when ready. Verification is retained if the email domain is unchanged; a different domain needs a new verification.
Changes invalidate SSO attempts already in progress. Keep an administrator password session available while testing, and ask affected members to restart from the login page after a change.
Disabling or disconnecting
Disable SSO stops domain routing while keeping the configuration. Disconnect removes the configuration and requires credentials again when reconnecting. Neither operation erases existing account-to-provider identity bindings or provides a way to reassign an identity to a different person.