> ## Documentation Index
> Fetch the complete documentation index at: https://docs.browserbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SSO (single sign-on) with SAML

> Learn how to enable SAML 2.0-based Single Sign-On for your Browserbase organization

Browserbase supports **SAML 2.0-based Single Sign-On (SSO)** so your team can log in with your corporate identity provider (IdP).

<Info>
  SSO is available only on Enterprise plans. [Get in touch](https://www.browserbase.com/contact) with the Browserbase team to enable SSO on your account.
</Info>

## Supported identity providers

Any **SAML 2.0-compliant IdP** is supported, including:

* Okta Workforce
* Microsoft Entra ID (formerly Azure AD)
* Google Workspace (SAML)
* Custom SAML providers

## How setup works

Setting up SSO requires coordination between your IT team and Browserbase support. Here's the process:

**Example:** Acme Corp wants to enable Okta SSO for their Browserbase organization.

### Step 1: Your IT team shares IdP configuration

Your IT administrator sends the following details from your identity provider to [support@browserbase.com](mailto:support@browserbase.com):

* **Sign-on URL (SSO URL)** - Where Browserbase redirects users for authentication
* **Entity ID / Issuer** - Your IdP's unique identifier
* **X.509 Signing Certificate** - Used to verify SAML assertions

### Step 2: Browserbase provides service provider details

The Browserbase team responds with configuration values your IT team needs:

* **Assertion Consumer Service (ACS) URL** - Where your IdP sends authentication responses
* **Entity ID (Audience URI)** - Browserbase's unique identifier
* **Metadata URL** - Complete SAML configuration (preferred method)

### Step 3: Your IT team configures the SAML application

Your administrator creates a new SAML application in your IdP (e.g., Okta, Azure AD) using the Browserbase SP details.

### Step 4: Joint testing

Both teams coordinate to test the login flow and verify that user attributes are mapped correctly.

### Step 5: Browserbase enables SSO

Once testing is successful, the Browserbase team enables SSO for your organization.

## Required attributes

Browserbase requires the following attributes in the SAML assertion:

* **Email address** – The user's email
* **First name** – The user's given name
* **Last name** – The user's surname

### Okta configuration

In your Okta SAML application, navigate to **SAML Settings** and configure the **Attribute Statements** section:

| Name        | Name Format | Value            |
| ----------- | ----------- | ---------------- |
| `mail`      | Unspecified | `user.email`     |
| `firstName` | Unspecified | `user.firstName` |
| `lastName`  | Unspecified | `user.lastName`  |

<Info>
  **Name** is the attribute name Browserbase expects—these must match exactly as shown (`mail`, `firstName`, `lastName`).

  **Value** is the Okta expression that retrieves the data from your directory. The values shown above (`user.email`, `user.firstName`, `user.lastName`) are Okta's default user profile attributes. If your organization uses custom attributes, adjust the Value accordingly (e.g., `user.primaryEmail` or `appuser.email`).
</Info>

### Other identity providers

For other SAML providers (Microsoft Entra ID, Google Workspace, etc.), ensure your attribute statements use the same attribute names:

* `mail` for email address
* `firstName` for given name
* `lastName` for surname

The source values will differ based on your IdP's attribute schema.

## Testing

**SP-initiated login** (recommended): Start from the Browserbase login page → redirected to your IdP → redirected back after successful authentication.

## Next steps

1. Collect your IdP configuration values.
2. Share them with Browserbase at [support@browserbase.com](mailto:support@browserbase.com).
3. The Browserbase team will reply with the SP details.
4. Test and finalize the integration together.

<Check>
  Once complete, your users can securely log in to Browserbase with SSO.
</Check>
