Just signing in? (team members)
If your workspace has Google or Microsoft sign-in enabled, you don't need any of the setup below — that's for your admin. To sign in:
- 1Go to the sign-in page and click Sign in with Google or Sign in with Microsoft.
- 2Approve the consent screen at Google or Microsoft — you'll land straight in, no password needed.
- 3First time, or you see "no account matches that sign-in"? The button won't create a new account on its own — your workspace admin has to add you first (your work email must match). Ask them to invite you, then try again.
Don't see those buttons? Then this workspace uses email + password or its own single sign-on — sign in as normal, or ask your admin. Admins: the rest of this page is the setup guide.
How it works
DataScene Tenders speaks OpenID Connect — the OAuth 2.0-based authentication protocol that every modern IdP supports. We discover your IdP's endpoints automatically from its .well-known/openid-configuration document, verify ID tokens against its published JWKS, and use the verified email claim to find or create the matching user in your workspace.
The flow at a glance
- 1. User clicks Sign in with SSO on
/loginand enters their work email. - 2. We look up your org config by email domain and 302 the browser to your IdP's authorize endpoint.
- 3. Your IdP authenticates the user and redirects back to
/auth/sso/callback?code=…. - 4. We exchange the code for an ID token, verify its signature + iss + aud + expiry against your IdP's JWKS.
- 5. We find the user by stable subject ID (or by email for first-time SSO), set a session cookie, and land them on /bids.
Two modes
Platform Google & Microsoft
When DataScene's operator has registered platform-level OAuth apps, "Sign in with Google" and "Sign in with Microsoft" buttons appear on the login page. No JIT — only existing accounts can sign in. New users must be invited first.
Per-org BYO-IdP This guide
Your org's admin registers your own IdP at your SSO settings. JIT provisioning creates accounts on first sign-in for users whose email domain matches your allowed list.
Before you begin
- You're the workspace admin. Only admins can configure SSO. Check at your team settings — your row should show the Admin badge.
- You have IdP admin access to register a new OIDC application. In Google Workspace this means the OAuth consent screen in Google Cloud Console; in Microsoft Entra ID it's "App registrations"; in Okta it's "Applications".
- You know your allowed email domains — usually one (your company's primary domain) but multiple is fine (parent + subsidiary, or main + alias domains).
- The redirect URI to register with your IdP — visible inside the config form at your SSO settings. Typically
https://<your-tenders-host>/auth/sso/callback.
Generic step-by-step
-
1
Register an OIDC application in your IdP
Create a new app (sometimes called "client" or "integration"). Pick web application as the type. You'll get back a Client ID and Client Secret.
-
2
Set the redirect URI
Add
https://<your-tenders-host>/auth/sso/callbackto the allowed redirect / sign-in URIs. This is the URL your IdP will send the user back to after they authenticate. The exact path is shown at the bottom of the config form on the SSO settings page. -
3
Grant the standard OIDC scopes
Enable
openid,email, andprofile. We don't need any group/role claims — your workspace's allowed-domain list is the gate. -
4
Note your issuer URL
The base URL where
.well-known/openid-configurationlives. Examples below. Must start withhttps://— HTTP is rejected. -
5
Paste into DataScene Tenders
Go to your SSO settings. Paste the issuer URL, client ID, client secret, and list your allowed email domains (one per line). Hit Enable SSO. We run an immediate discovery check — if your issuer URL is wrong, you'll see "discovery failed" instead of a successful save.
-
6
Test the sign-in
Open an incognito window. Go to
/login. Expand "Sign in with your organisation's SSO". Enter your work email. You should be bounced through your IdP and land back logged in.
Worked examples by provider
Google Workspace
In Google Cloud Console → APIs & Services → Credentials → Create credentials → OAuth client ID:
- Application type: Web application
- Authorized redirect URI:
https://<your-tenders-host>/auth/sso/callback - Scopes (configure on the consent screen):
openid email profile
Then in DataScene Tenders → /account/team/sso:
- Issuer URL
https://accounts.google.com- Client ID
- The Client ID string ending in
.apps.googleusercontent.com - Client secret
- The Client secret generated by Google (starts with
GOCSPX-) - Allowed domains
- Your Workspace primary domain — e.g.
yourcompany.com
Microsoft Entra ID (Azure AD)
In Entra admin center → App registrations → New registration:
- Name: e.g. "DataScene Tenders SSO"
- Supported account types: Accounts in this organizational directory only (single tenant)
- Redirect URI (Web):
https://<your-tenders-host>/auth/sso/callback
After creating: Certificates & secrets → New client secret → copy the Value (not the ID) — Entra only shows it once.
Then in DataScene Tenders → /account/team/sso:
- Issuer URL
https://login.microsoftonline.com/<tenant-id>/v2.0- Client ID
- The Application (client) ID — a GUID
- Client secret
- The secret Value from step above
- Allowed domains
- Your primary domain — e.g.
yourcompany.com
Okta
In your Okta admin dashboard → Applications → Create App Integration:
- Sign-in method: OIDC - OpenID Connect
- Application type: Web Application
- Grant types: Authorization Code
- Sign-in redirect URI:
https://<your-tenders-host>/auth/sso/callback - Assignments: Allow everyone in your organization to access (or scope by group as your policy dictates)
Then in DataScene Tenders → /account/team/sso:
- Issuer URL
https://<your-tenant>.okta.com- Client ID
- The Client ID from the General tab
- Client secret
- The Client secret from the General tab
- Allowed domains
- Your primary domain
Just-in-time (JIT) user provisioning
Once SSO is enabled, anyone in your org whose email matches your allowed-domain list can sign in for the first time and we'll auto-create their account. They join as a member (admin role is reserved for explicit transfer — see Roles & admin transfer).
What we trust from the IdP
- • Email address (must be in your allowed-domain list)
- • Email verified flag (required for platform Google/Microsoft; optional for per-org IdPs since you control them)
- • Display name (used for the user's profile)
- • Subject ID (stable per-user identifier for re-login)
What we don't trust
- • Group claims for role mapping — admin is always transferred deliberately
- • Custom claims — we only read the standard OIDC ones
- • Tokens from any IdP other than the one you configured
Troubleshooting
"Discovery failed" when saving the config
We tried to fetch {issuer}/.well-known/openid-configuration and it didn't return a valid OIDC discovery document. Common causes: typo in the issuer URL, a trailing slash that shouldn't be there, or your IdP not yet propagating a freshly-created app. Wait 1–2 minutes and try again.
"No DataScene account matches that sign-in"
The user's email domain isn't in your allowed-domain list. Either add their domain at your SSO settings, or have them sign in with platform Google/Microsoft (if you have an existing local account for them).
"We couldn't verify the sign-in token"
The ID token's signature didn't validate against your IdP's JWKS — usually because the IdP key rotated in the middle of the flow (rare) or the client ID we have doesn't match the audience the IdP issued the token for. Double-check the client ID matches exactly.
User signs in but their old role is lost
Existing users (those with a DataScene account before SSO was set up) keep their existing role on first SSO sign-in. Only brand-new accounts created via JIT are forced to member. If a user reports losing their admin status, check if the original admin still holds it — admin can only ever sit with one user.
I need to rotate the client secret
Generate a new secret in your IdP, then paste it into the same form at your SSO settings and save. We never echo the old secret back — you can't see it once stored.
I want to disable SSO entirely
"Disable SSO" button at the bottom of the config page. Existing SSO-linked users keep their email — they just need to reset their password (via the forgot-password flow) to sign in with email/password instead.