Access that keeps up as your org changes

SSO works with any identity provider that supports SAML 2.0 or OIDC, including Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, Rippling, Ping Identity, and Auth0. SCIM provisioning follows the SCIM 2.0 standard and accepts the request formats Okta and Entra ID send, so those are the most common pairings. Other SCIM 2.0 clients work too, as long as they filter with a single equals condition, since Basedash doesn't support bulk operations, sorting, or ETags.

SCIM syncs users, groups, and group memberships. For each user it carries the email address (the SCIM userName, which can't change after provisioning), first name, display name, job title, active status, and your directory's external ID. Groups are created, renamed, and deleted from the identity provider, and adding or removing someone there updates their Basedash membership. Roles and resource permissions aren't synced: provisioned people join as members, and admins decide in Basedash what each group can access.

Synced groups become Basedash groups, and an admin grants each one access. Data source grants decide who can query a source in chat, dashboards, exports, the SQL editor, and variables, and dashboards can be shared with specific groups. On Postgres, Basedash also passes the asker's groups to the database in the basedash.groups session variable, so row-level security policies filter what every AI answer can read. Customer-facing embeds are scoped by signed tokens instead, as described under embedding.

When your identity provider deactivates or unassigns someone, it sends a SCIM request and Basedash deactivates their organization membership as soon as it arrives. They lose access to the organization's data, and their open chats are re-scoped right away, so timing depends only on how quickly your provider sends the change. Their dashboards, charts, and audit history stay in place for the team. A SCIM delete also deactivates instead of erasing, re-provisioning the same email restores the same membership, and the last active admin can't be deactivated.

Yes. Once SSO is configured for a verified domain, everyone with an email address on that domain has to sign in or sign up through your identity provider. You add the domain in Settings, verify it with a DNS TXT record, and can let people with that domain join the organization automatically. Organizations that don't use SAML can instead require every member to sign in with Google.

SSO and SCIM are part of the Enterprise plan, along with audit logs, and only organization admins can configure them. They're also included in self-hosted deployments, where SCIM uses the same endpoints at your own base URL with no extra environment variables. If SCIM requests return 403 Forbidden, the token is valid but the organization isn't on a plan that includes provisioning. See Enterprise for the rest of the plan, or self-hosting to run Basedash in your own infrastructure.

An organization admin opens Settings, then Security, and creates a named SCIM token. It starts with bd_scim_ and is shown only once, since Basedash stores just a hash. In Okta or Entra ID, create a SCIM 2.0 app, set the base URL to https://charts.basedash.com/scim/v2, and use the token as the bearer token. Test the connection, then assign the people and groups that need access. To rotate, create a new token, swap it in, test, and revoke the old one.