Log in to Bito via Single Sign-On (SSO)

Single Sign-On (SSO) lets your team authenticate with Bito using your organization's identity provider (Google Workspace, Okta, Azure AD, Keycloak, and others) instead of a separate email and one-time code.

Once a workspace admin sets up SSO, it's available in two places:

1. Bito login — Team members sign in to the Bito web app itself through your identity provider. This is covered in detail on this page.

2. AI Architect MCP login — Team members authenticate the AI Architect MCP in their coding agents (Cursor, Windsurf, VS Code, etc.) through the same identity provider. See the AI Architect MCP SSO integration guide for setup and usage details.

Both use the same underlying SSO configuration — an admin sets it up once, and it applies to both Bito login and AI Architect MCP login.

Email OTP (one-time code) sign-in remains available for everyone, even after SSO is enabled. SSO is an additional sign-in option, not a replacement.

Why use SSO

When teams rely only on email and one-time code or shared credentials, it's hard to keep track of who has access and to revoke it quickly when someone leaves. SSO extends the identity system your organization already uses for email, Slack, and other business tools to Bito as well, so you get:

• Centralized, automatic enforcement of your existing security policies (like multi-factor authentication)

• Immediate access revocation when someone leaves your identity provider

• A simpler sign-in experience for your team

Supported identity providers

SSO implementation uses Descope as the authentication platform, which provides native integrations with enterprise identity providers.

Common identity providers include:

• Google Workspace

• Okta

• Azure Entra ID

• Microsoft AD FS

• PingFederate

• PingOne

• onelogin

• Keycloak

• JumpCloud

• Auth0

• ClassLink

• Cyberark

• Descope

• Duo

• LastPass

• miniOrange

• Salesforce

If your organization uses a different provider, you can configure it as a custom SAML 2.0 or OpenID Connect (OIDC) integration.

The setup process varies by provider but follows the same general pattern: you'll configure an application in your identity provider, exchange metadata or configuration details, and test the connection.

Prerequisites

To enable SSO for your workspace, you need:

1. Workspace admin access in Bito. You can check your role from the Manage Users dashboard.

2. Identity provider access — access to configure your organization's IdP (Google Workspace, Okta, etc.), typically held by an IT admin or someone on your identity and access management team.

How to configure SSO

SSO is configured once per workspace and applies to both Bito login and AI Architect MCP login.

1

Access SSO settings in Bito

1. Log in to Bito Cloud.

2. Navigate to the Manage integrations dashboard.

3. Under Available integrations, find Single Sign-On (SSO) and click Connect.

4. Click Connect via SSO and follow the setup wizard to connect your identity provider.

2

Configure your identity provider

The SSO configuration uses Descope as the authentication platform, which supports multiple identity providers.

1. In the Welcome page, click SSO Configuration.

2. Choose your identity provider from the list. If you do not find the identity provider, use the generic configuration options such as SAML 2.0 or OpenID Connect (OIDC) at the bottom of the screen.

3. Follow the provider-specific setup wizard to configure SSO.

For the sake of this documentation, we'll provide setup guide for Keycloak. For other identity providers, simply follow the step-by-step instructions provided by Descope in the setup wizard.

Guide for Keycloak:

1. From the Identity Provider (IdP) Selection screen, click Keycloak.

2. Click SAML.

3. From the Service Provider Information screen, copy Client ID.

4. Log in to the Keycloak administration console and follow these steps:

   1. In the left menu, select Clients, and click on Create client.

   2. Select SAML as the Client type, name the client, and paste the Client ID you copied above in the Client ID field.

   3. Click Next.

   4. From the Service Provider Information screen of the Descope setup wizard, copy SP ACS URL.

   5. Now in Keycloak administration console, paste the SP ACS URL to the Valid redirect URIs and the Master SAML Processing URL fields.

   6. Click Save.

   7. Scroll down, enable the Sign assertions toggle and click Save.

   8. In the top menu, select Keys and disable the Client signature required toggle.

   9. In the top menu, select Client scopes, and click on the newly created client.

   10. Select Add predefined mapper.

   11. Select x500 email, x500 givenName and x500 surname, and click Add.

   12. In the left menu, select Realm settings.

   13. Copy the SAML 2.0 Identity Provider Metadata link address.

   14. Now in Descope setup wizard, open Identity Provider Information screen.

   15. Paste the SAML 2.0 Identity Provider Metadata link address you copied from Keycloak administration console in the SAML 2.0 Identity Provider Metadata field.

   16. Click Continue.

   17. In the SSO Domains screen, click Continue.

   18. In the Testing screen, click Save & Test.

   19. If the configuration is done correctly, you will see SSO test completed successfully.

   20. Click Done, and you will be redirected back to Bito.

   21. In Bito Cloud, Manage integrations dashboard, you will see Setup completed for Single Sign-On (SSO) integration.

How users sign in to Bito with SSO

Once SSO is set up for your workspace, here's what your team members see when signing in to Bito.

1. On the Bito login page, the user enters their email address and continues.

2. If the user's organization has SSO configured for at least one workspace, they land on a Choose a workspace screen instead of going straight to the OTP screen.

3. This screen lists the workspace(s) available to the user that have SSO enabled, each with a Sign in button next to it.

4. The user clicks Sign in next to the workspace they want to access and is redirected to their organization's identity provider to authenticate.

Only workspaces that have SSO enabled appear with a Sign in button on this screen. If the user belongs to other workspaces that don't have SSO enabled, they can still reach those by choosing Sign in with email OTP instead.

1. After successful authentication, the user is signed in to Bito for that workspace.

Signing in with email OTP instead

At any point on the Choose a workspace screen, a user can click Sign in with email OTP instead to skip SSO and use the standard email one-time code flow. This is also what everyone sees if their organization hasn't set up SSO at all.

The user enters the code sent to their email, then selects the workspace they want to access.

Removing access

You have two options for removing someone's access, and they work differently.

1. If you remove someone from your workspace in Bito, their access is revoked immediately for new authentication attempts. However, if they have an active session (they're already authenticated in their IDE), that session will continue to work until it expires. Sessions expire after 1 hour of inactivity by default.

2. If you need to revoke access immediately, including active sessions, you should remove or disable their account in your identity provider (Google Workspace, Okta, etc.). This prevents them from authenticating at all, and their existing sessions will fail the next time they try to use Bito's AI Architect MCP in their coding agents.

For employees leaving the company, the standard practice is to disable their account in your identity provider as part of your offboarding process. This automatically revokes their access to Bito along with your other business applications. If you want to preserve their workspace membership for record-keeping but remove their Bito's AI Architect access, you can unassign their seat instead.