Single sign-on

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.

Choose a default template

People who arrive through SSO for the first time are given the default template you choose here. The template decides what a new member can do and which projects they can do it in, so pick one that matches the access a typical new joiner should have. See Templates to author one. Leave the default unset and new members arrive with no capabilities until you assign a template by hand.

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, and assigns the default template. There's nothing to pre-create: anyone in a verified domain who can authenticate at your provider becomes a member on first sign-in.

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.