TestDino SSO and SCIM Provisioning

Set up per-organization SSO with OIDC or SAML 2.0, and provision users automatically with SCIM, from the TestDino settings UI.

What you’ll learn

• How to connect your IdP with OIDC or SAML 2.0
• How the slug builds your sign-in URLs
• How to enforce SSO and set a default role for new users
• How to provision users automatically with SCIM

Single sign-on connects your organization to your company identity provider (Okta, Azure AD, Google Workspace, or any OIDC / SAML 2.0 IdP), so your team signs in with their existing credentials. You configure it per organization under Settings → Single Sign-On. No engineering work is needed.

Quick Reference

Step	What you do	Where
1	Open the SSO settings	TestDino
2	Pick a protocol and slug	TestDino
3	Configure your identity provider	Your IdP
4	Set enforcement and a default role	TestDino
5	Save and test sign-in	Both
6	Set up SCIM provisioning (optional)	Both

Before you start

• An Owner or Admin account. Only Owners and Admins see the Single Sign-On tab.
• SSO enabled on your plan. The tab appears only for SSO-entitled organizations, so contact [e-mail] if it is missing.
• IdP admin access to create an app integration.
• Your TestDino domain, such as https://app.testdino.com.

How it fits together

SSO coordinates 2 systems that must agree on the same URLs:

1. Your IdP: the app and who may use it.
2. TestDino (Settings → Single Sign-On): the IdP address, signing material, and policy.

The link is your slug (lowercase letters, digits, and hyphens, such as acme). TestDino builds every URL from it.

Sign-in (start):     https://<your-testdino-domain>/api/auth/sso/<slug>/login
OIDC callback:       https://<your-testdino-domain>/api/auth/sso/<slug>/callback
SAML callback (ACS): https://<your-testdino-domain>/api/auth/sso/<slug>/saml/callback
SAML SP metadata:    https://<your-testdino-domain>/api/auth/sso/<slug>/saml/metadata
SCIM base URL:       https://<your-testdino-domain>/scim/v2

The callback or ACS URL you register in your IdP must match the slug saved in TestDino, with no trailing slash and no typos. A mismatch is the most common reason sign-in fails. Pick the slug first, then use it on both sides.

Configure SSO

1. Open the SSO settings

   Go to Settings → Single Sign-On. You see two cards:

   • Single sign-on holds the protocol and IdP config.
   • SCIM provisioning holds the token. It stays disabled until you save an SSO config.

   No tab means you are not an admin, or the organization is not SSO-entitled.

2. Pick a protocol and slug

   Protocol	Use it when
   OIDC	Default. Modern OAuth-based sign-in. Works with most IdPs.
   SAML 2.0	Only if your IT policy requires XML-based sign-in.

   Enter your slug before you set up the IdP. It becomes part of every sign-in URL, so changing it later breaks existing links.

3. Configure your identity provider

   Create an app in your IdP, copy its values into TestDino, then save. The fields below use Okta as the example. Azure AD and Google Workspace use the same fields under different menu names.

   OIDC

   In your IdP, create an OIDC web app with the Authorization Code grant type, set the sign-in redirect URI, and assign your users.

   Okta path: Applications → Create App Integration → OIDC / Web Application, set the redirect URI, then open Assignments and save.

   Set the redirect URI to:

   https://<your-testdino-domain>/api/auth/sso/<slug>/callback
   

   Value to enter in TestDino	Where to find it in Okta
   Issuer	Security → API → Authorization Servers → default → Issuer URI
   Client ID	App → General → Client Credentials
   Client secret	Same section → Show → copy (shown once)

   In TestDino, paste the Issuer, Client ID, and Client secret. The secret is encrypted at rest and never shown again.

   If Okta returns “Policy evaluation failed”, add an access policy: Security → API → Authorization Servers → default → Access Policies, then add a policy and rule that allows the Authorization Code grant for your assigned users.

   SAML 2.0

   A SAML app is separate from an OIDC app, so create a new one.

   In your IdP, create a SAML app with these fields:

   Field	Value
   Single sign-on URL (ACS)	https://<your-testdino-domain>/api/auth/sso/<slug>/saml/callback
   Audience URI (SP Entity ID)	testdino-<slug>
   Name ID format	EmailAddress
   Application username	Email

   Add three attribute statements: email = user.email, firstName = user.firstName, lastName = user.lastName. Then assign your users.

   Okta path: open the app’s Sign On tab, click View SAML setup instructions, and copy the Identity Provider Single Sign-On URL and the X.509 Certificate (PEM).

   In TestDino, enter the IdP Single Sign-On URL, the SP Entity ID (the same Audience URI), and the full PEM certificate, including the BEGIN and END lines. Extra whitespace is fine.

4. Set enforcement and a default role

   • Require SSO for these domains blocks password sign-in for any email on those domains and sends those users to your IdP. At least one domain is required when this is on.
   • Default role is the role assigned on a user’s first SSO sign-in. Member is typical, and Admins can change it later.

Save and test

Click Save changes. The status badge shows Active · OIDC or Active · SAML.

Test in an incognito window:

1. Start the sign-in

   Open https://<your-testdino-domain>/api/auth/sso/<slug>/login.

2. Sign in at your IdP

   Complete the login with your IdP credentials.

3. Confirm the result

   You return signed in, and the user appears in your organization.

Just-in-time (JIT) provisioning: the first SSO sign-in creates the account, assigns the default role, and adds it to the matching-domain organization. Later sign-ins reuse the same account.

How your team signs in

Once SSO is active, your team has three ways to sign in:

• IdP app tile in your identity provider (IdP-initiated).
• Direct link to …/api/auth/sso/<slug>/login.
• Email discovery with “Continue with SSO” on the login page.

Set up SCIM provisioning

SCIM provisions TestDino users from your IdP automatically: create, update, and deactivate. Save an SSO config first, then generate a token in the SCIM card. The token is shown once.

Configure your IdP’s provisioning with these values:

Field	Value
SCIM connector base URL	https://<your-testdino-domain>/scim/v2
Unique identifier	userName
Auth mode	HTTP Header (Bearer token)
Bearer token	the copied token

In Okta, a custom app does not show a SCIM toggle. Add the prebuilt SCIM 2.0 Test App (Header Auth) from the catalog, open Provisioning → Configure API Integration, enable it, enter the base URL and token, test the credentials, then enable Create, Update, and Deactivate under “To App” and assign users.

What each SCIM action does

IdP action	Effect in TestDino
Assign	Creates the user and adds org membership. Repeat assigns are idempotent.
Update	Updates the user’s name.
Deactivate / unassign	Disables the user but keeps org membership, so reactivation works.
Reactivate	Re-enables the user.
Delete	Removes the user from the organization.

Day-2 operations

Task	How
Rotate the SCIM token	SCIM card → Rotate. Update your IdP connector right away, since the old token stops working at once.
Rotate the OIDC secret	Create a new secret in your IdP, paste it into Client secret, and save. Leaving it blank keeps the current secret.
Pause SSO	Clear enforcement to allow password sign-in again.
Switch protocol	Saving the other protocol replaces the sign-in config but keeps your SCIM token. Update the IdP callback or ACS path to match.

Troubleshooting

Symptom	Cause	Fix
IdP: “redirect_uri must be a Login redirect URI”	Callback URL does not match the slug	Set the IdP redirect URI to exactly …/sso/<slug>/callback (or …/saml/callback)
Okta: “Policy evaluation failed”	No access policy, or the user is not assigned	Add an access policy and rule on the default auth server, then assign the user
SAML: “idpCert is not in PEM format”	Certificate not pasted as full PEM	Paste the whole certificate, including the BEGIN and END lines
SCIM test fails: “Missing or malformed bearer token”	Wrong or blank token	Re-paste the exact token and set auth mode to HTTP Header (Bearer)
No Single Sign-On tab	Not an admin, or the org is not SSO-entitled	Get admin access, or contact support
Password login refused with an SSO message	Enforcement is on for that domain	Sign in with SSO, or remove the domain from enforcement
Cannot sign in after deactivation	Expected. Deactivated accounts are blocked.	Reactivate through your IdP (SCIM) or in TestDino
”User limit reached” on sign-in or SCIM	The plan seat limit is full	Free a seat or upgrade the plan

Seat limits apply to new users only. A net-new SSO sign-in or SCIM create is blocked when the org is at its limit, but existing members signing in again are never blocked.

Related

Users, Roles & Permissions

Understand the roles a new SSO user can receive.

Organization Settings

Manage your organization profile and ownership.

Security & Compliance

Review how TestDino handles credentials and customer data.

Generate API Keys

Create keys for CLI uploads and integrations.