Configure Single Sign-On

smplkit supports federated sign-in for your team through your own identity provider — Okta, Microsoft Entra ID, Google Workspace, Ping, OneLogin, Auth0, JumpCloud, and any other provider that speaks SAML 2.0 or OpenID Connect. Once configured, your team signs in to smplkit using the same credentials and policies they use for the rest of your stack.

Single Sign-On is an Enterprise capability. If your account is on a lower plan, the section described below will surface an upgrade affordance instead of the configuration form.

This guide assumes you have OWNER or ADMIN role on the smplkit account and the equivalent administrator role in your IdP.

At a glance

Setting up SSO is three steps:

1. Claim and verify the email domain your users sign in with — for example acme.com. You'll publish a DNS TXT record to prove you control it.
2. Register smplkit as an application in your IdP. smplkit gives you the Service Provider metadata to paste over; your IdP gives you back the values smplkit needs.
3. (Optional) Enforce SSO to disable password and Google/Microsoft sign-in for users on your verified domains. The account owner keeps password sign-in as a recovery path.

After step 2, anyone on a verified domain who clicks Sign in with Single Sign-On is routed to your IdP. New users are provisioned automatically the first time they sign in.

Step 1 — Claim and verify your domain

In the smplkit console, go to Account → Single Sign-On → Domains and click Claim. Enter the domain your users sign in with (for example acme.com).

smplkit returns a DNS TXT record that looks like this:

smplkit-domain-verification=<long random token>

Publish that record on the domain you claimed. The lookup is on the apex name — for acme.com you publish the TXT at acme.com, not at a subdomain. Different DNS providers display this differently:

• Route 53 / Cloudflare / Namecheap / GoDaddy: add a new TXT record, name @ (or leave blank), value as shown above, no quotes.
• Squarespace / Wix: look for the "advanced DNS" or "custom records" page.
• Internal DNS: add to your authoritative zone file and reload.

Allow a few minutes for the record to propagate, then click Verify in the smplkit console. On success the domain shows as Verified and is ready to route sign-ins.

Verified-domain ownership is global across smplkit. If you try to verify a domain that another smplkit account has already verified, you'll get a clear error — domains are first-come-first-served.

You can claim multiple domains on the same account (for example acme.com and acme.co.uk). Each one verifies independently.

Step 2 — Connect your identity provider

The fields you fill in here depend on which protocol your IdP speaks. Pick the protocol your IdP supports and follow that path. If your IdP supports both, OIDC is simpler to configure — pick it unless you have a specific reason to use SAML.

Open Account → Single Sign-On → Connection in the smplkit console and click Configure SSO.

OpenID Connect

In your IdP, create a new OIDC application (sometimes called "Web Application" or "Confidential Client"). When the IdP asks for redirect URIs, paste the ACS URL from the SP metadata block in the smplkit console.

The IdP will then give you three values to paste back into smplkit:

smplkit field	What your IdP calls it
OIDC Issuer	"Issuer", "Authority", or https://<your-domain>/.well-known/openid-configuration minus the .well-known/... suffix
OIDC Client ID	"Client ID" or "Application ID"
OIDC Client Secret	"Client Secret" or "Application Secret"

Some IdPs require you to configure the scopes the application can request. smplkit asks for openid, profile, and email. Some IdPs also require you to expose a groups claim if you want to use group-to-role mapping (see below).

SAML 2.0

In your IdP, create a new SAML application. Paste these values from smplkit's SP metadata block:

IdP field	Value from smplkit
Audience / Entity ID	SP Entity ID
ACS URL / Single Sign-On URL	ACS URL
Single Logout URL (optional)	SLO URL
NameID format	EmailAddress

The IdP will then give you back:

smplkit field	What your IdP calls it
SAML IdP Entity ID	"Identity Provider Issuer", "Entity ID", or "Audience URI"
SAML IdP SSO URL	"SAML Login URL" or "SSO Endpoint"
SAML IdP SLO URL	(optional) "SAML Logout URL" — fill in if you want smplkit to send LogoutRequests
SAML IdP X.509 Certificate	The signing certificate, PEM-encoded

Make sure your SAML application is configured to sign assertions. smplkit rejects unsigned assertions.

JIT provisioning and roles

The first time a user signs in via SSO, smplkit creates the user and assigns them a role on the account. You control how the role is chosen:

• Default role is what every JIT-provisioned user gets unless a group mapping overrides it.
• Group → role mappings let you say "anyone in the smplkit-admins IdP group becomes an ADMIN; anyone in smplkit-viewers becomes a VIEWER." The first mapping that matches one of the user's group claims wins.

JIT never auto-creates the OWNER role — there's exactly one OWNER per account, and ownership is an explicit transfer, not something assigned at sign-in. If you map a group to OWNER, smplkit downgrades it to ADMIN for new memberships.

Existing memberships are never re-roled by SSO. If a user already has a role on the account, signing in via SSO doesn't change it. Update roles in Account → Users if you need to.

Step 3 — (Optional) Enforce SSO

By default, configuring SSO adds a sign-in path — it doesn't remove password or Google/Microsoft sign-in. Users on your verified domains can use whichever path they like.

When you're confident your IdP is working and every team member is provisioned, you can flip Enforce SSO on the connection. Once enforced:

• Users on your verified domains can no longer sign in with a password or with Google/Microsoft. Attempts are rejected with a clear "Sign in with Single Sign-On" message and a link to the SSO path.
• The account owner is exempt — the owner retains password sign-in as a recovery path. If your IdP becomes unreachable, the owner can still get into the smplkit console and reconfigure or disable SSO.
• Users on domains you haven't claimed are unaffected. They sign in through whichever path they used before.

You can flip enforcement back off at any time. Doing so re-enables password and social sign-in for everyone immediately.

How sign-in works once it's configured

A user navigates to the smplkit sign-in page and clicks Sign in with Single Sign-On. They enter their work email. smplkit looks up the email's domain, finds the matching verified claim and connection, and redirects them to your IdP. The IdP authenticates them according to your policies (MFA, conditional access, whatever you've set up). Your IdP redirects them back to smplkit, smplkit mints a session, and the user lands in the console.

For users who already have a smplkit account on a different sign-in path, the first SSO sign-in links the existing user to the federated identity — they don't get a duplicate account.

Adjusting and removing the connection

Both the connection and the claimed domains can be changed at any time:

• Edit the connection to rotate the OIDC client secret, change SAML metadata, adjust the default role, or update group mappings.
• Switch protocol (OIDC ↔ SAML) by editing the connection and selecting the other protocol. The previous protocol's fields are cleared.
• Remove the connection to disable SSO sign-in entirely. The verified domains are kept — re-add a connection later and SSO routing resumes without re-verifying.
• Release a domain to take it out of SSO routing. Users on that domain go back to using password / social sign-in.

If your subscription drops below Enterprise, the connection and domains are preserved but SSO sign-in is paused — users fall back to password and social sign-in automatically. Re-upgrading restores SSO without re-configuration.

Troubleshooting

"DNS TXT record not found" on verify. Double-check the record is on the apex name, not a subdomain. Use a tool like dig +short txt acme.com to confirm the record is visible from the public internet before retrying.

"This domain has already been verified by another account." Someone else's smplkit account already holds this domain. If that's not expected, contact support.

Users get "Sign in with Single Sign-On" rejected when they try password sign-in, even though SSO isn't configured. Check that Enforce SSO is off, or that the user's email isn't on a domain you accidentally enforced.

An SSO sign-in succeeds but the user lands on a screen saying "your account has no membership." The user's email is recognized but they're not on this account. Invite them through Account → Users first, then have them try SSO again.

The IdP says "AudienceRestriction failed" or similar. Your IdP is sending the assertion to smplkit but with the wrong audience. Re-copy the SP Entity ID from the smplkit console into your IdP — they have to match exactly, including scheme and any trailing path segment.

SAML sign-in fails with "SAML assertion has expired" right away. Check the clock on your IdP. SAML assertions are valid for a short window and smplkit allows a ±2-minute skew; a clock that drifts further than that produces this error.