Single sign-on
Let your team sign in with your identity provider over SAML or OpenID Connect, then require it for your email domains.
Set it up in Settings → Security → Single sign-on. You need the "Manage single sign-on, SCIM, identity verification and roles" permission.
Choose a protocol
Most identity providers support both. OpenID Connect is quicker to set up; pick SAML if your IT team standardises on it.
Add Cueston to your identity provider
SAML: create a SAML app with these values, and send the email address as the NameID or an email attribute.
| Field | Value |
|---|---|
| Entity ID (audience) | https://app.cueston.com/api/auth/sso/saml/metadata/<connection id> |
| ACS URL (reply URL) | https://app.cueston.com/api/auth/sso/saml/acs |
| Metadata URL | The same as the entity ID. Use it if your provider imports metadata. |
OpenID Connect: create a web app (authorization code flow) with the redirect URI https://app.cueston.com/api/auth/sso/oidc/callback, and request the openid, email and profile scopes.
Settings shows the exact values for your connection, plus a sign-in URL for your provider's app tile. Point the tile there: sign-ins started from the provider's dashboard without it are refused, which protects against forged sign-ins.
Paste your provider's details
- SAML: the single sign-on URL, the identity provider issuer and the signing certificate.
- OpenID Connect: the issuer URL, client ID and client secret. The secret is encrypted and never shown again.
Choose who signs in this way
List your email domains, like acme.com. Prove you own each one by publishing a DNS TXT record at _cueston-verification.<domain> with the value Settings shows (cueston-domain-verification=…), then choose Verify. Unverified domains do nothing. Shared mailbox domains such as gmail.com can't be used.
Pick the role for new people. With just-in-time provisioning on, anyone your identity provider lets through joins the workspace with that role. With it off, only people you invited (or provisioned with SCIM) can sign in.
Test the connection
Test connection signs you in at your identity provider and shows what it sent back. Nobody's access changes and no session is created. Changing any setting resets the test.
Require single sign-on
Once a test passes and a domain is verified, you can require it. People at your verified domains can then only sign in through your identity provider: password sign-in, sign-up and password resets are refused for them. Anyone already signed in with a password stays signed in until their session ends.
Owner break-glass access
The workspace owner keeps password sign-in even when single sign-on is required, so you can get back in if your identity provider is down or misconfigured.
A session that started with single sign-on only reaches its workspace. People who joined through it get a member.joined webhook with source: "sso".