Sell to companies that ask for single sign-on
Their IT team connects Okta, Microsoft Entra, Google Workspace or any SAML or OIDC provider, through your own WorkOS account, and runs its own people, roles and access policy inside your app.
Three steps to the first company sign-in
You set up WorkOS once. Each company you sell to then sets up its own side.
Connect your WorkOS account
Paste your WorkOS client ID and API key in the console. BuildBase checks the key with WorkOS before it stores anything, and runs the sign-in itself.
Send the company's IT admin a setup link
Add the company, then invite its IT admin by email. They verify the company's domains and connect its identity provider in WorkOS, with no BuildBase account of their own.
Its people sign in with their company account
Continue with SSO asks for a work email and sends each person to their company's identity provider. Require single sign-on when the company wants no other way in.
What each company gets
Grouped the way a company's IT and security teams will ask about it.
Single sign-on
Each company you sell to signs its people in through its own identity provider, set up by its own IT admin.
- SAML and OIDC sign-in through your own WorkOS account
- The company's IT admin connects its identity provider from a setup link
- Domains the company's IT admin verifies in the WorkOS Admin Portal
- Verified domains send each person to their company sign-in
- A company can sign its people in through more than one identity provider, each email domain sent to its own, with a choice on the sign-in page where a domain has two; each one is a connection in your own WorkOS account
- Single sign-on can be required per company, so its people cannot use another way in
Provisioning and joining
People arrive in the right workspaces with the right role, and leave when the company's directory says so.
- A first sign-in lands people in the workspaces you choose, with the role you set
- Directory Sync (SCIM) adds and updates people, blocks leavers and maps directory groups to roles
- Roles from the identity provider at each sign-in, without SCIM
- Joining by email domain: anyone on the company's verified domains joins it, or asks to, and accounts already there can be claimed
- A policy for people outside the company in its workspaces: allowed, held to a role, or kept out
Company admins, roles and groups
Each company runs its own corner of your app, apart from the workspace admins.
- Company admins apart from workspace admins, named in the app or by the company's identity provider
- Company roles: Company admin, Security admin, Auditor, or the company's own, each viewing or managing only the areas it names
- Groups each company makes itself, by hand or from its identity provider's groups, that give workspace access and a role, can sit inside one another, and can have managers who keep their people current
- The company's IT admin can assign its identity provider's groups to the company's roles and groups in the WorkOS Admin Portal, and you hear when they need attention
- Company admins confirm it's them, at their identity provider or with a passkey, before the company's security settings change
Access policy and sessions
The rules a security team asks for, set by the company for its own people.
- Each company's access policy: how long sessions last, an IP allowlist, break-glass people for when its identity provider is down, which ways its people may sign in without single sign-on (passkeys only, if it wants), each person's sessions by device, ending one session, one person's or everyone's, and stricter rules for any of its workspaces (shorter sessions, fewer addresses, fewer ways in, single sign-on required) that never loosen its own
- Each company can keep its network to its own accounts: its proxy names the company, and any other account is refused there
- Each company sees every session your team opens as one of its people, and can refuse them
Audit trail, alerts and monitoring
What happened, who to tell, and what is about to break, in the company's own hands.
- Each company's own audit trail of sign-ins and provisioning, which its admins can read and export as CSV or through the API, and, once you turn it on through your own WorkOS account, view, export and keep for up to ten years in the WorkOS Admin Portal
- Each company's trail includes who joined, left or changed role in its workspaces
- Each company's activity streamed to its own SIEM: an HTTPS endpoint, Datadog or Splunk, or, through your own WorkOS account, WorkOS's destinations, such as AWS S3, Google Cloud Storage, Microsoft Sentinel and Snowflake
- Identity insights for each company: who signs in, how, and who was refused
- A warning before a company's SAML certificate expires, with a renewal link for its IT admin
- An alert when a company's IT admin turns its connection off or deletes it
- Each company's IT and security contacts, the people WorkOS emails about expiring certificates and connection errors, kept by its IT admin in the WorkOS Admin Portal and shown in your console, your app and the company API
Keys, workloads and agents
The company's scripts, CI jobs and AI agents reach your app without a person's password.
- Company API keys with scopes, so a company's compliance tools and scripts read its trail and manage its settings
- Company-owned service accounts whose keys outlive staff changes
- Each company's CI and cloud workloads can act as its service accounts by exchanging their own short-lived tokens, so no company API key is stored in CI
- Each company sees, disconnects and limits the apps and agents its people connect
- Each company's identity provider can approve the AI agents that act for its people, with no consent screen, and their access ends when it stops approving them or the person leaves
Where it is run from
Your team, the company's own admins and the company's tools each get a place of their own, so enterprise requests stop landing in your support queue.
In your console
Open Authentication, then Enterprise. Your WorkOS connection lives there, and each company gets a page of its own: its sign-in connection and domains, the accounts its directory adds and removes, its workspaces, access policy, admins, roles and groups, keys, where its logs are sent, activity and insights. Your team's side needs nothing built.
In your app, for the company
A Single sign-on screen in workspace settings lets the company's own admins look after themselves. They check their connection, open the setup page for their IT admin, and manage their policy, people, groups, roles, keys and audit trail, without asking your team. You can also put the same pieces (the Enterprise components and hooks) on pages of your own. Needs SDK 1.0.0 or later.
From the company's own tools
The company's scripts and compliance tools call an API of their own, with keys the company makes. Each key can do only what it was allowed to: read the audit trail, read people, sign people out, change the policy and more. A key is shown once and never stored in a form anyone can read back.
On your webhooks
Your own systems hear about 40 kinds of enterprise event as they happen, by webhook (a message BuildBase sends to your server) or as a workflow trigger, so nothing has to keep checking. They include a sign-in certificate about to expire, a person added or removed by the company's directory, a policy change and an emergency sign-in that skipped SSO.
Ready for the security questionnaire
The questions a company's security team sends before it signs, answered by how the sign-in is built, not by a promise.
The page to forward to a company's IT admin- A company sign-in finishes only in the browser where someone pressed Continue with SSO (PKCE). The code the identity provider sends back works nowhere else, so nobody can start a sign-in and have it finish in someone else's browser
- Your WorkOS API key is tested with WorkOS before it is saved, then stored encrypted. After that only a short preview of it is ever shown
- Company API keys are shown once and never stored in readable form. No key can create or manage other keys, so a leaked one can't make more
On the Enterprise plan, with your own WorkOS account
Enterprise identity is part of the Enterprise plan. Single sign-on and Directory Sync run through your own WorkOS account, so WorkOS bills those connections to you directly, for the companies that use them.
Compare plansFrequently Asked Questions
Which plan includes enterprise SSO?
The Enterprise plan. Single sign-on and Directory Sync run through your own WorkOS account, so WorkOS bills those connections to that account directly, and you pay WorkOS for the companies that use them.
Do I need my own WorkOS account?
Yes. BuildBase uses WorkOS for single sign-on and directory sync and runs the sign-in itself. You paste your WorkOS client ID and API key in the console, BuildBase checks the key with WorkOS before it stores anything, and the key is never shown again in full.
Which identity providers work?
Any SAML or OIDC provider, such as Okta, Microsoft Entra, Google Workspace. Each company's IT admin connects its own from a setup link, and never needs a BuildBase account to do it.
Can a company make single sign-on the only way in?
Yes. With single sign-on required, the company's people are refused at every other way in, with a sentence telling them to continue with SSO. A company that does not require it can still narrow the other ways in, down to passkeys only, and name break-glass people for when its identity provider is down.
What happens if my plan stops including it?
New setup is refused: a new company, domain, key, role, group or log stream answers 402 until the plan includes it again. Nothing that already works stops. People keep signing in with their company account, directories keep syncing, and removing or turning anything off is never refused.
Where do a company's own admins manage it?
In your app, without asking your team. A Single sign-on screen in workspace settings lets the company's own admins check their connection and open the setup their IT admin uses. They also manage their access rules, people, groups, roles, keys and audit trail there. The screen needs @buildbase/sdk 1.0.0 or later. Your team sees every company on the Enterprise tab of the console, and the company's own tools can call the company API with keys of their own.
How is the SSO sign-in itself protected?
Only the browser that pressed Continue with SSO can finish that sign-in, through PKCE, a standard safeguard for this. The company's identity provider (its own sign-in service, such as Okta) sends back a code that works once, and only in that browser. So a code copied from an address bar or a log signs nobody in. Nobody can start a sign-in and have someone else's browser finish it, either. Your WorkOS API key is checked with WorkOS before it is saved, and stored encrypted.
Close the deal that asked for SSO
Connect your WorkOS account, add the company, and send its IT admin the setup link. Its people sign in through their own identity provider.