Single Sign On

Single sign-on (SSO) is an arrangement where one identity provider authenticates a user once and asserts that identity to the other applications that user opens, so each application trusts a signed statement about the person instead of holding a password for them. The applications on the receiving end keep their own authorization rules and ask the identity provider only the question of who is signing in.

The operational result is one account record per person for the whole application estate. Adding someone happens in one directory, multi-factor and device rules are enforced in one place, and disabling the account closes the door to every connected application at once.

Definition

Three parties take part, and the names change between specifications while the roles stay the same.

• The principal. The person signing in, working through a browser.
• The identity provider (IdP). The system that holds the account record, runs the authentication challenge, and issues a signed statement describing the result. Directory products and hosted identity services fill this role.
• The service provider or relying party. The application the person wants to use. It consumes the signed statement, reads the subject and attributes out of it, and creates its own local session.

Trust between the identity provider and the application is configured once, before any user signs in. The two sides exchange the values each needs to recognize the other: an entity identifier and a callback URL on the application side, an issuer URL and a set of public signing keys on the identity provider side. After that exchange the browser carries every message, and the application verifies each statement against the keys it already has rather than calling the identity provider directly.

A sign-in then runs in five steps.

1. The person opens the application without a session, or starts from a tile in the identity provider's portal.
2. The application redirects the browser to the identity provider with a request naming itself as the intended audience.
3. The identity provider authenticates the person, using a password, a second factor, a device check, or an existing browser session it already holds.
4. The identity provider returns a signed statement about that person to the callback URL the application registered.
5. The application verifies the signature, reads the subject identifier and attributes such as email and name, and issues its own session cookie.

The two protocols in common use

Two specifications cover almost all enterprise deployments. Both do the same job, and the difference shows up in the format of the statement and the shape of the configuration screen.

The specifications themselves are public: SAML 2.0 at OASIS and OpenID Connect Core 1.0, both checked on 2026-08-13.

What sits outside the definition

Three neighboring things are often described as part of SSO and are separate mechanisms.

Authorization stays with each application. The statement says who the person is and may carry group memberships as attributes. What that person may do is decided by the application's own roles and policies after the session exists.

Provisioning is a different protocol. Creating, updating, and deactivating the account record inside each application is the job of SCIM, defined by RFC 7644. Some deployments use just-in-time provisioning instead, creating the local record on first successful sign-in, which covers creation and leaves deactivation unsolved.

Machine credentials never touch the browser flow. API tokens, deploy keys, and service accounts authenticate without a redirect, so a browser-based sign-in policy has no effect on them unless the application enforces one separately.

The third point is where most surprises live. Sessions and tokens issued before a change survive the change. Disabling an account stops new sessions from starting, and an open session or a long-lived token keeps working until something revokes it.

Example

A team enforces SAML sign-in on their GitHub organization so that one directory controls who reaches the code. Their build workflow checks out a second private repository using a personal access token stored as a repository secret.

name: build
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check out the shared internal library
        uses: actions/checkout@v4
        with:
          repository: example-org/shared-library
          token: ${{ secrets.INTERNAL_REPO_TOKEN }}
          path: vendor/shared-library

      - run: make build

The moment SAML SSO is enforced on example-org, that second checkout stops working. GitHub requires a personal access token or SSH key to be authorized for an organization that uses SAML SSO before it can reach that organization's resources, and an unauthorized token gets HTTP 403 back from the git request (GitHub documentation on authorizing a personal access token for use with SAML single sign-on, checked on 2026-08-13). The token's owner authorizes it once from their token settings page, and the workflow starts passing again.

That step is what connects the browser sign-in policy to a credential that never opens a browser. Enforcement gives the organization a list of exactly which tokens hold access, and revoking the authorization revokes the token's reach into the organization without touching the token itself.

Now the person who created that token leaves, and their account is deactivated in the identity provider. Two different outcomes follow, depending on how far the integration goes.

GitHub documents that removing a user through SCIM revokes the linked identity and the credential authorizations tied to it (GitHub documentation on SCIM for organizations, checked on 2026-08-13). Sign-in enforcement alone closes the browser path. Provisioning is what closes the token path, which is why a rollout that stops at SAML leaves a build credential alive after the person who owned it is gone.

The version of this workflow that survives a departure avoids the personal credential entirely. The automatic per job credential, GITHUB_TOKEN, belongs to the run rather than a person, and a GitHub App installation token belongs to the organization. Neither is affected when a contributor's directory account is deactivated, and both leave an attributable trail in the audit log.

Related Terms

• SSO for GitHub Actions runner access: how SAML 2.0 and OIDC sign-in is configured for a WarpBuild account, and what happens to runs-on labels during a rollout.
• Audit log, the record of who did what and when: what an audit log captures, how long entries are kept, and how a sign-in event is correlated with an action.
• Personal access token, the credential SSO enforcement gates: what a personal access token grants, how scopes and expiry work, and why SAML enforcement adds an authorization step.
• GITHUB_TOKEN, the automatic per job credential: where the token comes from, what it reaches, and how long it lasts.
• WarpBuild SSO documentation: the protocol choice, service provider values, assertion attribute mapping, and connection methods.
• WarpBuild runner security documentation: compute isolation, storage handling, and where build secrets sit.
• WarpBuild pricing: per minute rates by runner type.