> For the complete documentation index, see [llms.txt](https://docs.bito.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bito.ai/help/account-and-settings/log-in-to-bito-via-single-sign-on-sso.md).

# 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](https://alpha.bito.ai/) 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](/ai-architect/single-sign-on-sso-integration.md) 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.

{% hint style="info" %}
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.
{% endhint %}

## 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

{% hint style="info" %}
If your organization uses a different provider, you can configure it as a custom SAML 2.0 or OpenID Connect (OIDC) integration.
{% endhint %}

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](https://alpha.bito.ai/home/members) 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.

{% stepper %}
{% step %}

### Access SSO settings in Bito

1. Log in to [Bito Cloud](https://alpha.bito.ai/auth/login).
2. Navigate to the [Manage integrations](https://alpha.bito.ai/home/cra-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.
   {% endstep %}

{% step %}

### Configure your identity provider

The SSO configuration uses Descope as the authentication platform, which [supports multiple identity providers](#supported-identity-providers).

1. In the Welcome page, click **SSO Configuration**.
2. Choose your identity provider from the [list](#supported-identity-providers). 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](https://alpha.bito.ai/home/cra-integrations) dashboard, you will see **Setup completed** for **Single Sign-On (SSO)** integration.
       {% endstep %}
       {% endstepper %}

## 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](https://alpha.bito.ai/auth/login), 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.

{% hint style="info" %}
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**.
{% endhint %}

<figure><img src="/files/l73jpJCJZcVs6USEqVfv" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/7HP0r0AkvuQUG67MeZRj" alt=""><figcaption></figcaption></figure>

## 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bito.ai/help/account-and-settings/log-in-to-bito-via-single-sign-on-sso.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.