BrowserStack user provisioning with Okta

Connect your Okta IdP with BrowserStack.

Okta’s integration with BrowserStack enables end-users to enable Single Sign-on and Auto User Provisioning for their BrowserStack account. This document describes how to configure auto User Provisioning when Okta is your identity provider.

Prerequisites

• Enterprise plan on BrowserStack.
• Administrator access to your organization’s Okta instance.
• Single Sign-on integration with BrowserStack (mandatory).
• User with Owner permissions can setup user provisioning on BrowserStack.

Supported features

Okta & BrowserStack user provisioning integration currently supports the following features:

• User provisioning & de-provisioning
• Attribute assignment for users on BrowserStack:
  • Role assignment
  • Product access
  • Team assignment

For more information on the listed features, visit the Okta Glossary.

Configuring for user provisioning

1. Log in to BrowserStack as a user with Owner permissions.

2. Go to Account > Security and select Authentication from the side-nav menu.

3. Under Auto User Provisioning, click Configure.

4. Select the user attributes that you want to control from Okta and click Confirm.

5. Copy the credentials, will be used on Okta for authentication.

6. If you had already set up Signle Sign-On before setting up user provisioning, then you already have the BrowserStack application added on Okta. You can skip this step in that case, else:
   • Find BrowserStack application under Applications on Okta
   • Add it to your Okta tenant
   • Add Application label and click Done.

7. Go to BrowserStack application on Okta > Click Provisioning tab.

8. Click Configure API Integration.

9. Click Edit. Check Enable API Integration and fill the following details:
   • User name
   • Access Keys

10. Click Test API Credentials and upon successful test click Save.

11. Go back to BrowserStack’s Auto User Provisioning configuration page and click Done.

12. On Okta, click To App (on the left-hand menu) tab under Provisioning. Click Edit.
    • Check the following settings - Create Users, Update User Attributes, Deactivate Users.
    • Click Save.
13. Once you have completed the above steps, on BrowserStack, click Enable to enable user provisioning. If you don’t enable it, you will be locked out of inviting new users via BrowserStack UI.

Managing users from app on Okta

Once auto user provisioning is enabled, the user list will be controlled and managed from the Okta IdP.

Provisioning & de-provisioning users

1. For your existing users on BrowserStack, we would suggest that as a first step, assign all these users to the BrowserStack application (via the Assignments tab) in Okta. This would avoid any discrepancies between the user list on BrowserStack and Okta.
   • By assigning user(s) to the application, they will get provisioned on BrowserStack.
   • Users will be logged out of the BrowserStack, and will be redirected to log-in via SSO.

2. To add new users on BrowserStack, add these users in your Okta IdP and assign them to BrowserStack application via the Assignments tab. Invite modal will no longer be visible in the BrowserStack Account page anymore. If there were any existing invites already sent (before user provisioning was enabled), those invites will become invalid.

3. Any user can be removed from BrowserStack or their access by revoked by removing the user from the BrowserStack application on Okta.

BrowserStack attributes mapping

Go to Provisioning tab on Okta. Under BrowserStack Attributes Mapping section the attributes list is visible as shown:

Details about BrowserStack attributes and supported values for each of them:

To check the structure of these custom attributes, use the Schemas endpoint.

Migration steps

If you are already using an older version of the BrowserStack application on Okta, you can use the following steps to migrate to the new application.

BrowserStack has recently been updated to provide a better overall experience to Okta customers. Here is a summary of the changes:

• Control user provisioning and de-provisioning via Okta
• Configure control of User role, product access, and team via BrowserStack’s Okta application

To take advantage of these updates, you have to add a new instance of BrowserStack in your Okta org. If you already have an existing instance of BrowserStack, follow these steps to migrate from that old instance to a newly updated instance:

1. Log in to your Okta org as an Admin.

2. Open the Admin UI.

3. Click on Add Applications

4. Add a new instance of BrowserStack

5. Configure the Single Sign-On and Auto user provisioning, as per respective documentations:
   • Single Sign-On
   • Auto user provisioning

6. After SCIM Provisioning has been enabled, go to the Import tab of your new BrowserStack app instance. Select the old app as the source, and click Import Now.

7. After the users have been downloaded from the old version of the BrowserStack application, select the users you want to be created or linked in Okta, and then click on Confirm Assignments.

8. A pop-up will appear asking if you would like to proceed with the assignment confirmation. Click Confirm.

9. Users assigned on the old BrowserStack application have been imported into the new app.

BrowserStack SCIM endpoints

Okta talks to the BrowserStack SCIM server on the following endpoints. Use them to check which SCIM features BrowserStack supports, look up the structure of the custom attributes, and interpret the responses that appear in your Okta System Log.

Service provider configuration

The Service Provider Config endpoint returns the BrowserStack server’s authentication scheme and the optional or configurable SCIM features it supports. Service Provider Config objects are defined by RFC 7643, section 5.

GET https://www.browserstack.com/scim/v2/ServiceProviderConfig

Sample response:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"],
  "documentationUri": "https://www.browserstack.com/docs/enterprise/auto-user-provisioning",
  "patch": { "supported": true },
  "bulk": { "supported": false, "maxOperations": 0, "maxPayloadSize": 0 },
  "filter": { "supported": true, "maxResults": 500 },
  "changePassword": { "supported": false },
  "sort": { "supported": false },
  "etag": { "supported": false },
  "authenticationSchemes": [
    {
      "name": "OAuth Bearer Token",
      "description": "Authentication scheme using the OAuth Bearer Token Standard",
      "specUri": "http://tools.ietf.org/html/rfc6750",
      "type": "oauthbearertoken"
    }
  ],
  "meta": {
    "resourceType": "ServiceProviderConfig",
    "location": "https://www.browserstack.com/scim/v2/ServiceProviderConfig"
  }
}

Resource types

The Resource Types endpoint lists all of the SCIM resource types configured for use on the BrowserStack server. Use the response to determine the endpoint, core schema, and extension schemas of any resource type that the server supports. This endpoint does not provide resource type information about SCIM sub-resources.

The response is formatted as a list response, with one or more resource type objects in the Resources field. Resource type objects are defined by RFC 7643, section 6.

GET https://www.browserstack.com/scim/v2/ResourceTypes

Sample response:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 1,
  "Resources": [
    {
      "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
      "id": "Users",
      "name": "Users",
      "endpoint": "/Users",
      "schema": "urn:ietf:params:scim:schemas:core:2.0:User"
    }
  ]
}

User resource type

The Resource Type endpoint retrieves a specific SCIM resource type, specified by its ID. BrowserStack supports the User resource only. Resource type objects are defined by RFC 7643, section 6. This endpoint does not provide resource type information about SCIM sub-resources.

GET https://www.browserstack.com/scim/v2/ResourceTypes/User

Sample response:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ResourceType"],
  "id": "Users",
  "name": "Users",
  "endpoint": "/Users",
  "description": "User Account",
  "schema": "urn:ietf:params:scim:schemas:core:2.0:User",
  "meta": {
    "location": "https://www.browserstack.com/scim/v2/ResourceTypes/User",
    "resourceType": "ResourceType"
  }
}

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "Operations":[{"op": "add", "path" : "urn:ietf:params:scim:schemas:extension:Bstack:2.0:User:bstack_product", "value" : "App-Live-Testing,App-Automate-Testing"}]
}

Schemas

The Schemas endpoint lists the SCIM schemas configured for use on the BrowserStack server, which define the attributes available to resource types. Use this endpoint to check the structure of the custom primary_role, primary_team, and primary_product attributes. This endpoint does not provide schema information about SCIM sub-resources.

The response is formatted as a list response, with one or more schema objects in the Resources field. Schema objects are defined by RFC 7643, section 7.

GET https://www.browserstack.com/scim/v2/Schemas

Sample response:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 1,
  "Resources": [
    {
      "id": "urn:ietf:params:scim:schemas:core:2.0:User",
      "name": "User",
      "description": "User Schema",
      "attributes": [
        {
          "name": "userName",
          "type": "string",
          "multiValued": false,
          "required": true,
          "caseExact": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "server",
          "description": "Unique identifier for the User, typically used by the user to directly authenticate to the service provider. Each User MUST include a non-empty userName value. This identifier MUST be unique across the service provider's entire set of Users."
        },
        {
          "name": "name",
          "type": "complex",
          "multiValued": false,
          "required": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none",
          "description": "The components of the user's real name. Providers MAY return just the full name as a single string in the formatted sub-attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both.  If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined.",
          "subAttributes": [
            {
              "name": "familyName",
              "type": "string",
              "multiValued": false,
              "required": false,
              "caseExact": false,
              "mutability": "readWrite",
              "returned": "default",
              "uniqueness": "none",
              "description": "The family name of the User, or last name in most Western languages (e.g., 'Jensen' given the full name 'Ms. Barbara J Jensen, III')."
            },
            {
              "name": "givenName",
              "type": "string",
              "multiValued": false,
              "required": false,
              "caseExact": false,
              "mutability": "readWrite",
              "returned": "default",
              "uniqueness": "none",
              "description": "The given name of the User, or first name in most Western languages (e.g., 'Barbara' given the full name 'Ms. Barbara J Jensen, III')."
            }
          ]
        },
        {
          "name": "active",
          "type": "boolean",
          "multiValued": false,
          "required": true,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none",
          "description": "A Boolean value indicating the User's status."
        },
        {
          "name": "bstack_team",
          "type": "string",
          "multiValued": false,
          "required": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none",
          "description": "A String value indicating the User's Team in BrowserStack"
        },
        {
          "name": "bstack_role",
          "type": "string",
          "multiValued": false,
          "required": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none",
          "description": "A String value indicating the User's Role in BrowserStack"
        },
        {
          "name": "bstack_product",
          "type": "string",
          "multiValued": true,
          "required": false,
          "mutability": "readWrite",
          "returned": "default",
          "uniqueness": "none",
          "description": "A String value indicating the User's Product accesses in BrowserStack"
        }
      ],
      "meta": {
        "resourceType": "Schema",
        "location": "https://www.browserstack.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:User"
      }
    }
  ]
}

Individual schema

The Schema endpoint retrieves a specific SCIM schema, specified by its ID, which is always a URN. BrowserStack supports the User schema only. Schema objects are defined by RFC 7643, section 7. This endpoint does not provide schema information about SCIM sub-resources.

GET https://www.browserstack.com/scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:User

The response is the same User schema object that the Schemas endpoint returns in its Resources array, returned on its own without the list wrapper. For the full object, see the Schemas sample response.

Replace a user

The Replace User endpoint updates an existing user by replacing the resource with the values in the request body. You can update name, bstack_role, bstack_team, and bstack_product, and change the email through userName. You cannot update an attribute that your BrowserStack dashboard configuration controls.

PUT https://www.browserstack.com/scim/v2/Users/{id}

A successful request returns 200 with the full user resource, including externalId, active, and the custom bstack_* attributes:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": 12345,
  "externalId": "john.doe",
  "userName": "john.doe@example.com",
  "active": true,
  "name": { "givenName": "John", "familyName": "Doe" },
  "emails": [{ "primary": true, "value": "john.doe@example.com" }],
  "bstack_role": "Admin",
  "bstack_team": "Engineering",
  "bstack_product": "Live,Automate",
  "meta": {
    "resourceType": "User",
    "created": "2026-01-10T08:12:33.000Z",
    "lastModified": "2026-07-15T09:00:00.000Z",
    "location": "https://www.browserstack.com/scim/v2/Users/12345"
  }
}

In this response, userName carries the user’s email, and externalId carries the BrowserStack username.

Some fields are returned conditionally based on your SCIM configuration:

• bstack_role, bstack_team, and bstack_product are returned only when that attribute is controlled by the IdP in your SCIM configuration.
• meta is returned only for accounts enabled for the SCIM metadata response.
• id is an integer by default, and a string for accounts enabled for string user IDs.

Update a user

The Update User endpoint applies a partial update to an existing user using a SCIM PatchOp request. A replace operation that sets active to false de-provisions the user.

PATCH https://www.browserstack.com/scim/v2/Users/{id}

A successful request returns 200 with the full user resource, in the same shape as the Replace a user response, including the conditional fields described earlier:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": 12345,
  "externalId": "john.doe",
  "userName": "john.doe@example.com",
  "active": true,
  "name": { "givenName": "John", "familyName": "Doe" },
  "emails": [{ "primary": true, "value": "john.doe@example.com" }],
  "bstack_role": "Admin",
  "bstack_team": "Engineering",
  "bstack_product": "Live,Automate",
  "meta": {
    "resourceType": "User",
    "created": "2026-01-10T08:12:33.000Z",
    "lastModified": "2026-07-15T09:00:00.000Z",
    "location": "https://www.browserstack.com/scim/v2/Users/12345"
  }
}

Error responses

When a request fails, all endpoints return the same SCIM error envelope with an HTTP status code such as 400, 403, 404, or 422:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "detail": "Human-readable error message",
  "status": "404"
}

Common cases include:

• 403: Missing or invalid credentials.
• 404: The requested resource is not found.
• 400 or 422: Invalid request, or an attribute that is controlled by the BrowserStack dashboard as per the current configuration.

Troubleshooting

Below is a list of possible errors that might be encountered and how to resolve them:

Email already part of a different organization account on BrowserStack.

Resolution: User is already present on BrowserStack under a different organization, please reach out to BrowserStack support to get that account deleted before provisioning the user to your current organization account.

Invalid Parameter Or Attribute

Resolution: Role/Product is not a valid use-case, please use the attribute values provided above.

Owner deletion

Resolution: Assign ownership to a different user before deletion of this user. Owner cannot be deleted, BrowserStack account needs a user to have Owner role assigned.

Incompatible attributes

Resolution: You are assigning incompatible user attributes, for example Owner cannot have a team assigned.

Licenses unavailability

Resolution: You have used up all your licenses for the product, please unassign users or add more licenses. Contact your Account Executive to get information on adding licenses.

Escalation/Support

Contact us for any escalations or support.