---
id: platform/sso
title: SSO
description: Understand Bex sign-in, configured social providers, workspace invitations, and the boundary between social login and enterprise SSO.
keywords: [bex, sso, social login, oidc, github login, saml]
last_updated: 2026-09-23
---

Bex supports dashboard sign-in through its configured identity service. An
installation can offer GitHub social login alongside its other enabled sign-in
methods. Use the options shown on that installation's login page.

This is account sign-in. Bex does not currently provide per-workspace enterprise
SAML/OIDC connections, SCIM provisioning, email-domain capture, or enforced
workspace SSO policies. Do not treat GitHub login as a substitute for those
controls when evaluating or migrating a team.

## Sign in and join your workspace

1. Open your installation's Bex dashboard and choose an available sign-in method.
2. Complete any email verification or additional authentication the identity
   service requests.
3. If you received an invitation, use the account matching its email address.
4. Select the intended workspace and check that its resources are visible.

Your sign-in method does not choose your [workspace role](./members.md).
An admin invitation grants membership; a successful GitHub login alone does not.
Connecting GitHub for login is also separate from
[granting repository access](./github-integration.md) for builds.

## Self-hosted provider configuration

The platform operator configures social providers in the identity service;
workspace admins do not add a provider through a service API setting. Bex's
Kratos deployment loads a separate OIDC configuration fragment, and the GitHub
provider requires the operator's OAuth application and callback configuration.

A missing GitHub button usually means that provider is not enabled for the
installation. A failed provider redirect should be checked against the
installation's public URLs and registered callback, rather than worked around
by changing workspace permissions. Provider availability is not a promise that
every upstream identity-service integration has been configured or tested.

## Automation uses separate credentials

Use [API keys](./api.md) for machines and
[MCP authorization](./connect-an-agent.md) for agents. Do not copy a browser
session into a long-running integration. For an interactive terminal, the
[Bex CLI](../cli.md) offers a browser login flow:

```bash
bex login
bex workspaces -o json
```

Troubleshoot account sign-in first if the browser cannot authenticate. If sign-in
works but an API or agent operation is denied, check its scopes and workspace
permissions instead. For a migration requiring enterprise SSO or automated user
provisioning, resolve that unsupported requirement before moving the team.