Skip to main content
SAML single sign-on (SSO) is a foundational feature for enterprise identity on GitHub. Without SAML, your GitHub organization remains an identity silo: engineers must remember separate corporate and GitHub credentials, and revoking access when someone leaves requires manual steps in two systems.
A slide titled "A Separate Identity Silo" showing a corporate laptop (one login) that has no connection to a GitHub account (a completely different login). The caption reads "One engineer, two identities to remember."

​
How SAML SSO works (an analogy)

Think of SAML like a security checkpoint at a federal building. In this analogy, GitHub is the building. GitHub issues the visitor pass (the SAML session token), but it doesn’t verify identities itself—the identity provider (IdP) does that. Your IdP is the “federal ID office” (for example, Okta or Azure AD). When someone tries to enter, the GitHub guard asks the IdP whether the person is cleared.
A diagram titled "A Checkpoint at a Federal Building" showing a GitHub-styled building with a SAML checkpoint and two people at the entrance. To the right is a "Federal ID Office" that issues IDs via identity providers like Okta and Azure AD.
The guard does not use its own database; it queries the IdP. The IdP replies “yes, this person is cleared,” and the guard issues a visitor pass (the SAML session) so the person can enter GitHub.
An illustration showing a guard at a GitHub building checking with an ID Office (your IdP) about a person's clearance. Blue and green arrows show the guard asking "is this person cleared?" and the ID Office replying "yes, cleared."

​
Session lifetime

A SAML session is time-limited (commonly 24 hours). After expiry, users must re-authenticate with the IdP to receive a fresh session token.
The image is a simple diagram titled "Good for 24 Hours" showing a current "Visitor Pass" on the left, a circular "24 hours" timer in the center, and a "New Visitor Pass" on the right. It illustrates that the visitor pass is valid for 24 hours and then expires.

​
Availability dependency

Because GitHub defers authentication to your IdP, GitHub’s access becomes partly dependent on the IdP’s availability. If your IdP’s systems (authentication service, MFA provider, phone gates) are down, users cannot obtain a session token—effectively blocking access to the organization.
An illustrated slide titled "If the ID Office Goes Down" shows several people standing in line blocked by a broken phone connection to an "ID Office" building. A caption/button at the bottom reads "Nobody gets in."
Communicate this dependency clearly to stakeholders: implementing SAML SSO improves security and centralizes identity, but it also couples GitHub access to IdP reliability.

​
Enabling vs Enforcing SSO

A common operational pitfall is confusing “enabled” with “enforced.” The difference is critical: If you switch to Enforced while your admin account lacks an active IdP session (or while you haven’t authorized critical automation credentials), you can lock organization owners and admins out immediately.
A presentation slide titled "Locking Yourself Out" showing an admin user icon with a "no linked okta session" warning and an organization security dialog requiring SAML single sign-on. A stylized blue door labeled "your own organization" appears on the right.
Always verify an active IdP session for at least one org owner/admin account before switching SSO from enabled to enforced. Enforcing SSO without a valid admin session will lock owners and admins out of GitHub.
GitHub includes a “Test SAML configuration” button you should use to validate your Sign-on URL, Issuer, and certificate. Do not rely on guesswork—test before you enforce.
A settings screenshot for SAML single sign-on showing empty fields for Sign-on URL and Issuer, a "Test SAML configuration" button with a "Test successful" indicator, a checked "Require SAML single sign-on" option, and a Save button. The slide header reads "Test Before You Enforce."

​
What breaks immediately when you enforce SSO

When you flip enforcement on, any credentials that are not SAML-authorized for the organization will stop working—even though they still exist. This includes:
  • Personal Access Tokens (PATs) used by automation and scripts
  • OAuth apps that haven’t been granted organization access
  • SSH keys that haven’t been explicitly authorized for the organization
A slide titled "Existing Credentials Stop Working" shows a flowchart where enforcing SAML causes a "Production incident." It highlights that personal access tokens and SSH keys "stopped working" and are "not SAML authorized."
Typical failure symptoms include 401 responses from the API and SSH permission errors:

​
Recovery: how to restore access

To get things working again after enforcement, users and automation must explicitly authorize their credentials for the organization:
  • Personal access tokens and OAuth apps: Users must authorize these tokens/apps for the organization from their GitHub account settings (SAML authorizations).
  • SSH keys: Users must open Settings → SSH and GPG keys, locate the key, and click Authorize next to the organization.
Before enforcing SSO, prepare a step-by-step guide for developers and CI owners that explains how to authorize PATs, OAuth apps, and SSH keys. Include exact menu paths and screenshots if possible to reduce help-desk load.
Suggested rollout checklist:
  1. Identify owners and ensure at least one owner has an active IdP session linked to their GitHub account.
  2. Communicate the change widely (developers, CI/CD teams, release engineers, automation owners).
  3. Ask teams to pre-authorize automation tokens and verify CI systems’ credentials.
  4. Use the GitHub “Test SAML configuration” button to validate settings.
  5. Enforce SSO during a low-impact window and monitor CI and repo access logs.
  6. Provide a fast-response channel (Slack, email alias) for immediate troubleshooting.

​
Quick reference: common issues and fixes

Communicate the trade-offs: SAML SSO strengthens centralized identity and access controls, but it also introduces an availability dependency and requires careful planning—especially before enforcing SSO across an organization.

Watch Video