How Workbrew Console login and SSO enforcement work

The Workbrew Console offers several ways to sign in, and on Enterprise plans it can be configured so that a Workspace's users may sign in only through your identity provider. This page explains the login methods, what single sign-on (SSO) enforcement does once it is in place, and why enterprise SSO is treated differently from the social sign-in buttons that look similar. It is background reading for security and platform teams evaluating Workbrew or planning an SSO rollout.

The login methods#

The Workbrew Console sign-in page offers three kinds of authentication:

• Email sign-in. You enter your email address and the Console sends a one-time login link. No password is involved. This is the default method and the one every account can use out of the box.
• Social sign-in. Buttons for Apple, GitHub, Google, and Microsoft let you authenticate with a personal or work account at one of those providers. These are consumer OAuth logins. They prove you control that Apple, GitHub, Google, or Microsoft account, and nothing more.
• Sign in with SSO. You enter your organization's domain and are redirected to your organization's identity provider (for example Google Workspace or Okta) over SAML or OIDC. This is enterprise SSO, and it is the only method your organization's administrators control centrally.

A User is identified by their email address, so whichever of these methods is available to you resolves to the same account rather than creating a separate one per method.

Social sign-in is not SSO#

Social sign-in and Sign in with SSO can look interchangeable, and this is the distinction that causes the most confusion. They authenticate you in different ways, and only one of them is something your organization controls.

The social sign-in buttons are consumer identity. Each one verifies that you control an account at Apple, GitHub, Google, or Microsoft, and nothing more. The button is not directly tied to your company. What your organization does control is who can reach your Workspace, and, with SSO, which login methods are allowed at all. The sections below cover both.

Sign in with SSO is a connection your organization establishes with Workbrew through WorkOS, the identity platform the Console uses. It ties a verified email domain to your identity provider over SAML or OIDC, which is what lets your administrators decide who may sign in and enforce it. The Console treats only SAML and OIDC connections as SSO. A consumer OAuth button never counts as SSO, no matter which of the four providers it belongs to.

The confusion tends to come from providers that offer both. Google and Microsoft each run a consumer sign-in button and, separately, an enterprise identity service (Google Workspace, Microsoft Entra) that can act as a SAML or OIDC provider. Signing in with the Google button is not the same as signing in through Google Workspace SSO, even though both involve Google.

The practical consequence is that you cannot turn a social button into your organization's sole login method. To require everyone to sign in through a provider you manage, you connect that provider to Workbrew as a SAML or OIDC identity source through SSO, not through its consumer button.

What SSO enforcement does#

Once a Workspace has enterprise SSO configured, sign-in for that organization's users becomes SSO-only, automatically. There is no separate switch to disable the other methods. The restriction follows from having real SSO in place. For a user whose email is on the enforced domain:

• Email sign-in stops. Entering that email on the sign-in page no longer sends a login link. The Console redirects straight to your identity provider instead.
• The social buttons stop. Attempting to sign in with Apple, GitHub, Google, or Microsoft is rejected, with a message directing the user to sign in with SSO.
• Existing sessions end. Anyone already signed in through a login link or a social button is signed out on their next visit and sent to SSO. An old session cannot be used to sidestep the requirement.

From that point the only way in for those users is Sign in with SSO, through your identity provider.

Membership and login are governed separately#

Two distinct controls are at work, and it helps to keep them apart.

Allowed Domain governs who can be a member. On Pro and Enterprise plans, a Workspace can set an Allowed Domain in its settings. Once set, only users whose email is on that domain can be invited or added, and the setting cannot be turned on while members from other domains already exist. A Workspace is not obliged to stay open to outside accounts. An administrator who wants the Workspace restricted to their own organization sets this, and non-organization emails are refused at invitation time.

SSO enforcement governs how members sign in. Enforcement is keyed to the verified email domain, so users on that domain are held to SSO as described above. Because SSO enforcement expects an Allowed Domain to be in place, an Enterprise Workspace using SSO is typically already closed to outside members, and every remaining member signs in through your identity provider.

The two combine cleanly. Allowed Domain keeps the membership list to your organization, and SSO enforcement keeps those members on your identity provider. An external collaborator on a different domain using email sign-in only arises in a Workspace that has deliberately left Allowed Domain unset.

Why it works this way#

Restricting login to a single method is a control an organization should be able to enforce, and enforcing it requires an identity source the organization actually governs. A consumer OAuth provider does not qualify. Your company does not administer who holds an account at one of those providers, so binding your login policy to a social button would give you the appearance of control without the substance. A SAML or OIDC connection with a verified domain is administered by your identity provider, which is why the Console will enforce against it and not against the consumer buttons.

Scoping enforcement to the verified domain rather than the whole Workspace follows the same reasoning. Your policy should govern your organization's identities. It should not lock out a partner whose identity your organization does not manage and did not agree to place behind your identity provider.

Two smaller design choices are worth knowing. Policy changes are not instantaneous, because the Console caches the result of a domain's policy lookup briefly, so enabling or changing SSO can take up to about a minute to take full effect. The check also fails safe. If the identity platform cannot be reached at the moment of a lookup, the Console falls back to allowing email sign-in rather than locking everyone out during a transient outage.

Getting SSO for your Workspace#

Enterprise SSO is an Enterprise-plan capability, and the SAML or OIDC connection and verified domain are set up together with Workbrew rather than self-served from the Console. If you are on a Free or Pro plan, the login methods above are all available and none of the enforcement described here applies. To plan an SSO rollout, or to have enforcement enabled for your domain, contact Workbrew.

Related docs#

• How the Workbrew Agent uses elevated privileges - another security-and-compliance topic for teams evaluating how Workbrew handles trust and access.
• Managed brew access - how Workbrew governs who can run brew on a Device, a separate access control from Console login.
• Getting started with Workbrew - creating an account and Workspace, the entry point before any SSO configuration.