# Single sign-on and GitHub sign-in

How SendBeam signs people in through GitHub or a company identity provider (SAML 2.0), what an admin sets up once, and what happens on first sign-in.

SendBeam has three ways in: an email address with a password or a one-click link, a GitHub account, and single sign-on through a company identity provider. All three land the same person in the same account and workspaces; which one you use is a matter of convenience and policy, not of what you can do once inside.

## Sign in with GitHub

On the sign-in and sign-up pages, **Continue with GitHub** sends you to GitHub to approve SendBeam once, then straight back. SendBeam reads only your primary email address and display name. If that address already has a SendBeam login, GitHub signs you into it; if not, an account and a first workspace are created for you, named after your GitHub profile, and you can rename the workspace under Settings.

GitHub does not replace a password: an account that has one keeps it, and you can use either. Two-factor authentication set on your SendBeam account still applies after a GitHub sign-in.

## Single sign-on (SAML 2.0)

Single sign-on lets a company sign its people into SendBeam through the identity provider it already runs (Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin and any other SAML 2.0 provider). Leavers lose access when they are removed from the provider, and the provider's own policies for MFA and device trust apply.

It is available on the [Business plan](https://sendbeam.io/pricing). Setting it up is a one-time exchange with us:

1. Your identity provider admin creates a SAML application for SendBeam and sends us its **metadata URL** (or the metadata XML) and the **email domains** the company signs in with, through [the contact form](https://sendbeam.io/contact?s=sales).
2. We register the provider against those domains and reply with SendBeam's service-provider details for the application: the ACS URL and entity ID.
3. From then on, anyone with an address on those domains chooses **Use single sign-on** on the sign-in page, enters their work email, and is sent to your provider.

The attribute mapping we need is the standard one: the email address as the NameID (or an `email` attribute), and optionally `name`. A first sign-in through SSO creates the person's SendBeam login and, if they have not been invited to a workspace yet, a workspace of their own; invite them to the company workspace first under Settings → Team and they land there instead.

## Policies an admin can set

Under Settings → Team, a workspace admin can require two-factor authentication for every member. That applies to password and GitHub sign-ins; SSO sign-ins are governed by the identity provider's own policy.

---
Source: https://sendbeam.io/docs/admin/sso