Single sign-on

Configure SAML 2.0 single sign-on so your organization's members sign in through your own identity provider.

Single sign-on lets the people in your organization sign in to SikkerKey through your own identity provider, any SAML 2.0 provider such as Okta, Microsoft Entra ID, or Google Workspace, instead of a separate SikkerKey password. It's an organization feature, available depending on your plan, and the vault owner sets it up from the dashboard.

Before you start

  • Your vault must be an organization. Single sign-on doesn't apply to a personal vault.
  • It's available depending on your plan. If there's no Single sign-on page in your sidebar, either your vault isn't an organization yet or your plan doesn't include SSO.
  • You'll need admin access to your identity provider to register SikkerKey as an application, and access to your DNS to publish one record per domain.

Connect your identity provider

Open the Single sign-on page from the dashboard sidebar. SikkerKey needs three things from your provider: its entity ID, its sign-in URL, and its signing certificate. You can supply them two ways:

  • Upload metadata (recommended). Most providers publish a SAML metadata XML document. Upload it and SikkerKey reads the entity ID, sign-in URL, and signing certificate out of it for you.
  • Enter them by hand. Paste the entity ID, the sign-in URL, and the signing certificate in PEM form.

SikkerKey stores this configuration encrypted at rest, and it won't accept a certificate that's expired or not yet valid.

Hand your provider SikkerKey's details

Your identity provider needs to know who SikkerKey is and where to send members after they authenticate. The Single sign-on page lists the values to paste into the SikkerKey application on your provider's side:

  • the SP entity ID that identifies SikkerKey,
  • the ACS URL where your provider posts its signed response, and
  • a metadata URL, if your provider prefers to import SikkerKey's details rather than type them.

Verify your domains

SikkerKey only creates accounts for email domains you've proven you control. Add each domain on the Single sign-on page, publish the DNS TXT record it shows you at the host it names, and click Verify once the record is live. DNS can take a few minutes to propagate.

An unverified domain can't be used to sign in or to provision members. This is what stops a different organization from claiming accounts in a domain it doesn't own.

New members start minimal

People who arrive through SSO for the first time are added to your organization on the minimal Collaborator vault role with no access role. They can sign in and see the vault, but they reach no project until you raise their roles. Assign each new member's vault role and access role from the member roster once they appear. See Vault Roles & Access Roles for the model.

Enable, then optionally enforce

Two independent switches:

  • Enabled lets members sign in with SSO. Their existing password, passkey, or OAuth sign-in keeps working alongside it.
  • Enforced requires SSO. Password, passkey, and OAuth sign-in are refused for anyone whose email is in one of your verified domains. You, the owner, are always exempt, so a provider misconfiguration can lock out members but never locks you out of the dashboard you'd use to fix it.

Turning enforcement on ends members' current sessions so the policy applies immediately instead of waiting for those sessions to expire.

How members sign in

On the login page a member clicks Continue with SSO and enters their work email. SikkerKey finds the organization that owns that domain and sends them to your identity provider. They authenticate there, the provider posts a signed response back, and SikkerKey signs them in.

Just-in-time provisioning

The first time someone signs in through SSO, SikkerKey creates or links their account automatically, as long as their email domain is one you've verified. There's nothing to pre-create: anyone in a verified domain who can authenticate at your provider becomes a member on first sign-in, starting on the minimal Collaborator role until you assign them more.

Removing access

Disabling or removing someone at your identity provider stops them getting new SikkerKey sessions through SSO. On its own it does not remove their membership or end a session they already hold. To fully revoke someone, also remove them from your member roster; that drops their access on their next request. SikkerKey does not currently deprovision automatically from identity-provider changes.

How sign-ins are secured

SikkerKey validates every response from your provider before trusting it: the signature against your configured certificate, the audience and recipient, a freshness window, replay protection, and a binding tying each response to a sign-in SikkerKey actually started. The full model is in the Security Overview. If you have a passkey, saving changes to your SSO configuration prompts you to verify with it first, and every change is recorded in the audit log.