Single sign-on with SAML or OpenID Connect
Let your people sign in through Okta, Microsoft Entra ID, Google Workspace or any SAML / OIDC provider.
On the Enterprise plan, your organisation can sign in to SignSpry through its own identity provider. Set it up under Admin → Single sign-on & SCIM. Until you switch it on, nothing changes for anyone.
1. Verify your email domains
Add each domain your people's addresses use, such as example.com. SignSpry shows a DNS TXT record — publish it with whoever runs your DNS, then press Verify:
| Name | Value |
|---|---|
_signspry.example.com | signspry-verify=… |
Only addresses on a verified domain can sign in through your identity provider, and a domain can belong to one organisation only. Public mailbox domains such as gmail.com can't be claimed.
2. Connect your identity provider
Create an app for SignSpry in your identity provider using the details shown on the page.
- SAML 2.0: give it the Entity ID and the ACS URL (or point it at the
metadata URL), send the person's email as the NameID, and sign the assertion or the response. Then paste the provider's entity ID, single sign-on URL and signing certificate into SignSpry. Turn assertion encryption off.
- OpenID Connect: register the redirect URI shown, then paste the
issuer URL, client ID and client secret. SignSpry uses the authorisation-code flow with PKCE and asks for openid email profile.
For an app tile in your provider's dashboard, use the sign-in URL for app tiles shown on the page. Sign-ins must start from SignSpry or that URL; unsolicited (IdP-initiated) SAML responses are refused.
3. Test, then switch on
Test sign-in takes you to your identity provider and back and shows what it sent. Nobody is signed in by a test. When it works, tick Single sign-on is on. People then choose Sign in with single sign-on (SSO) on the sign-in page and enter their work email.
If Create a member the first time someone signs in is ticked, a new person from your domains gets the role you choose and uses a seat. Otherwise add them first under Admin → Users, or provision them with SCIM.
Requiring single sign-on
Tick Require single sign-on and members on your verified domains can no longer sign in with a password or Google, and the password-reset link isn't sent to them.
- Break-glass administrators keep password sign-in, so a broken identity
provider can't lock you out. Whoever switches the requirement on becomes one if there is none.
- API keys keep working.
- People outside your verified domains, other organisations, and anyone on your
domain who signed up with their own separate SignSpry account aren't affected.