Articles

Configure SAML SSO for Your GitHub Organization (2026)

April 18, 2026 4 min read

GitHub’s SAML Single Sign-On (SSO) isn’t just about convenience; it’s a critical security control that lets you manage access to your organization’s repositories using your existing identity provider (IdP).

Let’s see it in action. Imagine a user, Alice, who’s part of your company’s Active Directory. She needs to access a private repository in your GitHub organization.

  1. Alice tries to access github.com/my-org/my-repo.
  2. GitHub (the Service Provider, SP) intercepts this. It doesn’t know Alice.
  3. GitHub redirects Alice’s browser to your IdP. This redirect includes a SAML Request, essentially saying "Hey IdP, can you verify this user for github.com?"
  4. Your IdP prompts Alice for authentication (e.g., username/password, MFA).
  5. Upon successful authentication, the IdP generates a SAML Assertion. This is a digitally signed XML document containing information about Alice, like her username (email address), group memberships, and confirmation that she’s authenticated.
  6. The IdP sends this Assertion back to Alice’s browser.
  7. Alice’s browser, upon receiving the Assertion, POSTs it back to GitHub.
  8. GitHub verifies the Assertion’s signature (using a public key it has for your IdP). If valid, it checks if the assertion’s NameID (usually Alice’s email) matches a user in your GitHub organization.
  9. If there’s a match, GitHub grants Alice access to the repository based on the permissions associated with her GitHub account, which might have been provisioned or updated based on the SAML assertion’s attributes.

The core problem SAML SSO solves is the "identity sprawl" and the manual burden of managing user access across multiple systems. Instead of creating and managing separate user accounts and credentials for GitHub, you leverage your central IdP. This means:

  • Centralized User Management: When an employee joins or leaves, you manage their access in one place (your IdP), and it automatically propagates to GitHub.
  • Enhanced Security: Stronger authentication policies (like MFA) enforced by your IdP apply to GitHub access. Revoking access is immediate.
  • Simplified Onboarding/Offboarding: New hires get access quickly; departing employees lose it instantly.

To configure SAML SSO for your GitHub organization, you’ll need two main pieces of information:

  1. From your Identity Provider (IdP):

    • SSO URL (or Sign-on URL): The endpoint where GitHub will send SAML requests.
    • Public Certificate: The public key your IdP uses to sign SAML assertions. GitHub uses this to verify the assertions.
    • Issuer (or Entity ID): A unique identifier for your IdP.

  2. From GitHub (as the Service Provider, SP):

    • Assertion Consumer Service (ACS) URL: The endpoint on GitHub where your IdP will send SAML assertions. This typically looks like https://github.com/orgs/YOUR_ORG_NAME/saml/consume.
    • Audience URI (or SP Entity ID): A unique identifier for GitHub within your SAML setup. This is often https://github.com/orgs/YOUR_ORG_NAME.

You’ll input your IdP’s details into GitHub’s SAML configuration settings. Conversely, you’ll configure your IdP to recognize GitHub as a trusted Service Provider, using the ACS URL and Audience URI provided by GitHub.

Here’s a glimpse of what the configuration might look like in your IdP’s interface (this is illustrative, exact fields vary):

  • Application Name: GitHub Organization
  • Assertion Consumer Service (ACS) URL: https://github.com/orgs/my-awesome-org/saml/consume
  • Audience URI (SP Entity ID): https://github.com/orgs/my-awesome-org
  • NameID Format: EmailAddress
  • Attribute Statements:
    • email maps to user’s primary email
    • groups maps to user’s group memberships (for team provisioning)

And in GitHub’s organization settings:

  • SAML Single Sign-On: Enabled
  • Sign-on URL: https://idp.example.com/app/github-org/sso/saml
  • Public Certificate: -----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----
  • Signature Method: RSA-SHA256 (common, but check your IdP)
  • Digest Method: SHA256 (common, but check your IdP)

The most surprising part for many is how group memberships can be automatically provisioned and deprovisioned. When your IdP sends back group information in the SAML assertion, GitHub can use this to assign users to specific teams within the organization. This means you can manage repository access at a granular level directly from your IdP’s group structure, without ever touching GitHub’s team settings manually. For example, an IdP group github-repo-admin could automatically add users to the Owners team in GitHub, while dev-team-backend could add users to the backend-developers team.

Once SAML SSO is configured and enforced, users will be redirected to your IdP for authentication every time they access your organization’s resources on GitHub.

The next hurdle after setting up SAML SSO is often configuring SCIM provisioning to automatically create, update, and deactivate user accounts in GitHub based on changes in your IdP.

Want structured learning?

Take the full Github course →