Single Sign-On (SSO) lets your team sign in to Dapple using your existing identity provider — Okta, Microsoft Entra ID, Google Workspace, Auth0, or any other provider that supports OpenID Connect (OIDC) — instead of a Dapple password. You set it up in Organisation Settings → Security → Single Sign-On by registering Dapple as an application with your provider, entering its issuer URL, client ID and client secret in Dapple, then verifying the email domains SSO applies to. Once enabled, anyone signing in with a verified-domain email is redirected to your provider to log in. You can also enforce SSO so it becomes the only way in.
Please note - SSO is only available on Pro and Enterprise plans.
How does SSO actually work?
SSO works by handing authentication off to your identity provider instead of Dapple. When someone types their work email on the Dapple sign-in screen, Dapple checks whether that email's domain has SSO configured. If it does, Dapple sends the person to your provider — Okta, Entra ID, Google Workspace, Auth0, or another OIDC provider — to log in with their existing username and password.
Your provider then sends Dapple a signed response confirming who the person is, including whether their email address is verified. Dapple exchanges this for the final sign-in. This handoff is what the Client ID and Client Secret are for: they let Dapple prove to your provider which application is making the request, and let your provider prove the response really came from them.
What do I need before I start?
You need three things from your identity provider and one from your DNS provider:
From | What it's for |
Issuer URL | The base address of your provider, so Dapple can discover its OAuth endpoints |
Client ID | Identifies the Dapple application you register with your provider |
Client Secret | The confidential secret paired with the Client ID |
Access to your DNS | To prove you own each email domain with a one-time TXT record |
You'll register Dapple as a new application (sometimes called a "client", "app registration", or "connection") in your identity provider. Dapple gives you a Callback URL to paste back into that application once it's created.
How do I register Dapple as an application with my identity provider?
Open Organisation Settings → Security → Single Sign-On and copy the Callback URL near the bottom of the page (also called the "redirect URI" or "reply URL"). It follows this format:
In your identity provider, create a new OIDC web application, set its redirect URI to the Callback URL you copied (it must match exactly), and make sure the app can request the openid, email, and profile scopes. Your provider then generates a Client ID and Client Secret — copy both.
Provider | Where to create the app | Issuer URL format |
Okta | Applications → Create App Integration → OIDC / Web Application | |
Microsoft Entra ID | App registrations → New registration, add a Web redirect URI | |
Google Workspace | Google Cloud Console → APIs & Services → Credentials → OAuth client ID | |
Auth0 | Applications → Create Application → Regular Web Application | |
Other (Ping, OneLogin, JumpCloud, etc.) | Varies by provider | Provide the provider's OIDC issuer URL, e.g. https://<your-domain>.pingone.com/<env-id>/as for Ping |
How do I enter my provider details in Dapple?
Back in Organisation Settings → Security → Single Sign-On:
Under Provider, click your identity provider's button (Okta, Microsoft Entra ID, Google Workspace, or Auth0) to pre-fill the issuer format, or select Other and enter it manually.
In Issuer URL, paste your provider's issuer URL — the OAuth authorisation server base URL, not your Dapple app URL. For Google, use https://accounts.google.com.
In Client ID, paste the client/application ID from your provider.
In Client Secret, paste the client secret.
Click Save SSO Configuration.
Your client secret is stored encrypted and never shown again. To change it later, click Reset next to the secret field and enter a new one — leaving the field locked keeps the existing secret.
How do I add and verify an email domain?
SSO only applies to email domains you've verified, so Dapple knows you own them. The Verified Email Domains section unlocks after you save your SSO configuration.
Under Verified Email Domains, type your company domain (for example, company.com) and click Add domain.
Dapple shows a DNS TXT record to publish. Add it with your DNS provider.
Once the record is live, click Verify. DNS changes can take a few minutes to propagate — if it doesn't verify immediately, wait and try again.
Field | Value |
Type | TXT |
Name / Host | _dapple-verification.company.com |
Value | dapple-domain-verification=<your-unique-token> |
Public email providers (gmail.com, outlook.com, and similar) can't be verified for SSO.
A domain can be verified by more than one organisation — for example, subsidiaries sharing an email domain. Each publishes its own TXT record, and users are shown an organisation picker at sign-in.
You can add multiple domains if your company uses more than one.
How do I test my SSO connection before going live?
Click Test Connection on the Single Sign-On page. Dapple runs a behind-the-scenes health check and reports on provider discovery (your issuer URL exposes the expected endpoints), signing keys (your provider publishes them), client credentials (your Client ID and Secret are accepted), and the redirect URI you need registered. Testing never signs anyone in, so run it as many times as you like.
How do I turn on SSO — and should I enforce it?
Turn on Enable SSO — this only becomes available once at least one domain is verified — and click Save. From then on, anyone entering an email on a verified domain at the Dapple sign-in screen is redirected to your identity provider to log in. If their domain isn't set up for SSO, they get the usual sign-in link by email instead.
Enforce SSO for members goes a step further: everyone on your verified domains must sign in through your identity provider, and can't fall back to Google, Microsoft, Apple, or magic-link sign-in.
Confirm SSO works end-to-end — sign in yourself in a private or incognito window — before turning on enforcement. If your identity provider is misconfigured or unavailable once enforcement is on, even administrators can be locked out. If that happens, contact support@dapplehq.com.
What happens if I remove someone's access?
Removing a member from Dapple doesn't stop them signing in through SSO — your identity provider is still the source of truth for who can log in. To actually block someone, remove them from your identity provider as well as from Dapple.
If someone who was removed from Dapple signs in again through SSO, they're re-added automatically with default (non-admin) permissions rather than being blocked. They keep whatever access your default role grants, not the role they had before — so if they previously had admin access, that isn't restored automatically.
How do I manage or turn off SSO later?
Change the client secret — click Reset next to the secret and save.
Add or remove domains — manage them in the Verified Email Domains section. If you remove your last verified domain while SSO is still enabled, no one can sign in via SSO until you verify a domain again or disable SSO — Dapple warns you when this happens.
Turn SSO off — switch off Enable SSO and save. Members can then use the standard sign-in methods again.
Remove SSO entirely — click Remove SSO Configuration. This deletes your configuration and all verified domains; you'll need to re-verify them if you set SSO up again later. You'll be asked to confirm first.
Why isn't SSO working?
What you see | Likely cause & fix |
Issuer URL won't validate | Double-check the issuer URL — it's your provider's base URL, not your Dapple URL. Remove any trailing paths beyond what your provider specifies. |
"Client ID or secret was rejected" | Re-copy the Client ID and Secret from your provider. Click Reset and re-enter the secret. |
Error after logging in at the provider | Make sure the Callback URL is registered exactly in your provider's app, and that it can request the openid email profile scopes. |
"Email domain not allowed" | The user's email domain hasn't been added and verified for your organisation. Add and verify it. |
"Email not verified" | Your identity provider is reporting the user's email as unverified. Verify the user's email in your provider — Dapple never links unverified email addresses. |
Domain won't verify | Confirm the TXT record's Name/Host and Value match exactly, then wait a few minutes for DNS to propagate and try again. |
Best practice
Verify at least one domain and run Test Connection before enabling SSO — never enable it untested.
Sign in yourself in a private/incognito window before turning on Enforce SSO for members.
Keep your callback URL change process in sync with your DNS/IT team — the URL includes your organisation ID and won't match if copied from another org.
Don't use a public email provider domain (gmail.com, outlook.com) — Dapple blocks these for SSO.
If you remove someone's access, remove them from your identity provider too — removing them only from Dapple doesn't stop them signing back in.
Reset the client secret if you ever suspect it's been exposed — the old one stops working immediately.