authentik and GitHub Enterprise Cloud SAML SSO setup

How authentik enforces SAML SSO for GitHub Enterprise Cloud

authentik can act as the SAML identity provider for a GitHub Enterprise Cloud organization, and authentik publishes a dedicated guide for that setup. Separately, authentik publishes a different guide for GitHub Enterprise Managed Users (EMU) that combines SAML with SCIM provisioning. These are two distinct models with different identity ownership, so the platform team must choose one before configuring anything. The organization SSO guide keeps accounts as ordinary GitHub users who sign in through authentik, while the EMU model makes the identity provider the source of truth for accounts that GitHub itself creates and manages. Mixing the steps from both guides is the most likely way to end up with a half-working tenant.

For the organization SSO model, the core work is configuring a SAML application and provider in authentik that matches the GitHub Enterprise Cloud SSO settings, then enabling SAML enforcement on the GitHub organization. Decisions to make early include which authentik groups or flows may reach the application, how users are matched to existing GitHub accounts, and what happens to members who have not yet linked their identity. The platform team should confirm the current GitHub-side requirements for enforcement and recovery owners, and check the exact field names in the authentik guide against the live GitHub settings page, since both sides change over time.

Developers see the difference most directly in how they sign in. With organization SSO, they keep their personal GitHub accounts, authorize the organization through SSO, and may need to re-authenticate on a schedule set by the identity provider and GitHub. With EMU, developers sign in only with accounts issued through authentik, and the repositories and contributions they create live in a separate enterprise-managed namespace. Before choosing, the team should ask who owns existing public contributions and personal repositories, and whether engineers will need a second GitHub identity for open-source work.

Which GitHub model fits: SSO on existing accounts or Enterprise Managed Users

authentik publishes two separate guides for GitHub Enterprise Cloud: organization SAML SSO for existing accounts, and Enterprise Managed Users with SAML and SCIM. The choice depends on who owns developer accounts today and how much account lifecycle you want automated from the identity provider.

Organization SSO on existing accounts

This model keeps developers on their own personal GitHub accounts and requires them to link those accounts to the organization through SAML sign-in. authentik acts as the identity provider that enforces sign-in for members. Check whether your developers already hold personal accounts that they control, and whether those accounts already contain repositories, forks or gists you need to keep tied to work. Confirm with GitHub how membership is removed when someone leaves, because that step is not handled by the identity provider in this model.

Enterprise Managed Users with SAML

Enterprise Managed Users creates GitHub accounts that belong to the enterprise, and sign-in is handled through the identity provider rather than through a personal account. This is a different account model, so it changes how developers reach public repositories and existing personal work. Confirm with GitHub which personal-account activity remains available under Enterprise Managed Users before you choose it. Plan the username format and the email attribute that authentik sends, since these become the identity GitHub matches on.

Automated deprovisioning with SCIM

SCIM is the part of the EMU guide that creates, updates and suspends accounts from authentik. Without it, a person removed in authentik can keep an active GitHub session or membership until someone removes them by hand in GitHub. Ask who owns the leaver process, how fast access must be removed under your policy, and whether an audit trail of removals is required. Verify in a test enterprise that deactivating a user in authentik produces the expected change in GitHub before you rely on it.

Developer account ownership policy

Your policy on who owns the code identity matters more than the sign-in mechanics. If your organization requires that company-managed accounts hold all access to company repositories, the EMU model fits that rule. If developers must keep personal accounts for open-source contributions or for work outside the enterprise, the organization SSO model is usually the simpler route. Write down the rule first, then map it to a model. Confirm the current GitHub rules on account ownership, forks and public repositories with GitHub before the decision is final.

Migration and existing accounts

Moving from personal accounts to Enterprise Managed Users is not a simple switch on an existing organization. Developers may need new accounts, and repositories, secrets and integrations may need to be re-created or re-linked on the new identity model. Ask GitHub which assets carry over and which must be rebuilt, and inventory the repositories, Actions secrets and personal access tokens that depend on current accounts. Agree a cutover plan with a rollback path, since mistakes in account mapping are hard to undo once developers have signed in.

Developer sign-in experience

Developers will notice the change in how they sign in, how they authenticate and which account they use for commits and reviews. In the organization SSO model, developers keep their existing login and add an SSO step. In the EMU model, they sign in through the identity provider and may use a different username. Plan a short communication and a pilot group, and test the login path with MFA enabled in authentik. Confirm with GitHub which Git credentials and personal access token types each model supports for command-line and CI use.

What the GitHub plan and authentik edition cost you

The cost of this integration comes from two separate subscriptions: GitHub's per-user plan and the authentik edition you run. GitHub's pricing page lists Team at $4 and Enterprise at $21 per user per month. SAML single sign-on for a GitHub organization sits on the Enterprise tier, so the figure to budget for is the Enterprise rate. Decide first whether you need GitHub Enterprise Cloud or self-hosted GitHub Enterprise Server, because the two are priced and operated differently and the authentik guide you choose depends on that decision. Ask your GitHub account team to confirm the seat count, the billing period and whether any data residency option changes the price.

authentik itself is free under its Open Source edition, which is MIT licensed for most of the repository. The Enterprise edition is listed at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starts at $20k annually. The enterprise license covers only the code in the authentik/enterprise/ directory, so features gated there are a separate purchase from core. Confirm with authentik which features your chosen GitHub guide needs before you assume the free edition is enough. Ask whether the Enterprise rate applies to your full user population or only to users who sign in through the integration, and get the quote in writing with the license terms attached.

Your partner's fee is the part you cannot read off a price list. A fixed-scope engagement covers configuring the authentik side, the GitHub organization settings, testing and handover, and it recurs only if you buy support or upgrades. Ask for the quote to separate one-time build work from any ongoing retainer, to state which GitHub and authentik editions are assumed, and to list what changes if you move from Enterprise Cloud to Enterprise Server or add SCIM provisioning. Costs rise when the identity population is large, when you need Enterprise Managed Users, or when there are several organizations to connect.

Configure authentik as the SAML provider for GitHub Enterprise Cloud

This sequence sets up authentik as the SAML identity provider for a GitHub Enterprise Cloud organization, then turns on enforcement only after a non-admin test sign-in has passed. The result is one tested sign-in path that your team can roll out to members.

Confirm the GitHub and authentik prerequisites
Before changing anything, confirm that your organization is on GitHub Enterprise Cloud, that you hold an organization owner role, and that your authentik deployment is on a supported version. Confirm the current version list in the authentik security policy and the latest release on the authentik releases page, and plan any upgrade before the integration work starts. Check which GitHub plan and data residency option you use, because GHE.com regions are a separate subdomain with their own sign-in endpoints. Done when you have written down the organization name, the owner account that will hold admin access, and the authentik version you will test against.
Create the authentik application and SAML provider
In the authentik admin interface, create a SAML provider and an application that points to it, following the GitHub Enterprise Cloud guide in the authentik integrations catalog. Set the entity ID, ACS URL and audience values exactly as the GitHub SAML settings page expects them, and record the authentik-issued metadata and SSO URL. Restrict the application to a binding or policy so that only the intended group can start a sign-in. Done when the application appears in the authentik application library and its SAML metadata endpoint returns a valid XML document.
Set signing certificates and validate the metadata
Choose the signing certificate and signing behavior for the SAML provider, then export the metadata that GitHub will consume. Check that the signing certificate is valid, is not expired, and matches the one referenced in the metadata file. Validate the XML with an independent SAML metadata validator or your own tooling, and confirm that the NameID format and attribute names match what the guide specifies. Keep a copy of the certificate fingerprint in your change record so that later rotation is planned rather than discovered during an outage. Done when the metadata validates and the certificate details are recorded.
Configure SAML single sign-on in GitHub
As an organization owner, open the organization security settings in GitHub Enterprise Cloud and enable SAML single sign-on. Enter the sign-on URL, issuer and the signing certificate from authentik, following the field names the guide lists. Do not enforce SSO yet. Generate the recovery codes that GitHub offers for the organization and store them in your secrets management system, since they are the only fallback if the identity provider is unavailable. Done when GitHub shows the SAML configuration as saved and the recovery codes are stored outside the identity provider.
Assign users and groups in authentik
Add a test group in authentik that contains one non-admin user and one developer account that represents a typical member. Bind the SAML application to that group and confirm that users outside it cannot start the flow. Verify that the username or email attribute sent to GitHub matches the identity that members already use on the organization, because a mismatch creates duplicate or unlinked accounts. Done when the test group is bound and an unbound account is refused at the application.
Run a test sign-in from a non-admin account
Sign in to GitHub with the non-admin test account through the organization SSO link, while SSO enforcement is still off. Confirm that the browser is redirected to authentik, that authentication completes, and that GitHub links the session to the correct organization member. Repeat the test with a second account that already has organization membership to confirm that the link is not duplicated. Record any error codes and their resolution. Done when both test accounts reach the organization with their own identities and the test results are documented.
Enforce SSO for the organization
After the test sign-ins succeed, enable the enforcement setting in the GitHub organization SAML configuration. Members who have not linked their accounts will be asked to authenticate through authentik before they can reach organization resources. Tell members in advance that they will need an active authentik session, and that personal access tokens and SSH keys used with the organization may need to be authorized for SSO. Keep an owner account with the recovery codes available during the rollout window. Done when enforcement is on and a member without a linked session is prompted to sign in through authentik.

What changes for developers on each model

Under SAML SSO enforcement on a GitHub Enterprise Cloud organization, developers keep their own personal GitHub accounts. Nothing about the account itself is recreated, but the way they reach organization resources changes. Each developer signs in to GitHub through authentik, and then authorizes SAML access for the organization before they can use its repositories, packages or other resources. Access stays tied to the identity they already use on GitHub, which makes the change easier to explain to contributors who work across several organizations.

First sign-in: Developers link their GitHub account to the identity provider and complete the SAML sign-in once, then authorize the organization when prompted.
Existing sessions: Active sessions and tokens may need re-authorization after enforcement starts. Confirm the exact behavior in the authentik guide before the cutover date.
Personal access tokens and SSH keys: Tokens and SSH keys that touch organization resources may need to be authorized for SAML access. Confirm which credential types are affected and how developers authorize them.
Outside collaborators: Contractors and outside collaborators may fall outside the SSO requirement, so confirm how they are handled before enforcement.
Communication: Tell developers which credentials to re-authorize, where to do it, and who to contact when a sign-in fails.

Before rollout, check the token and SSH authorization steps against the current GitHub documentation in a test organization.

Attributes and groups mapped between authentik and GitHub

This table compares the identity fields authentik sends to GitHub under organization SAML SSO and under Enterprise Managed Users with SCIM, and the groups that map to teams or roles. Attribute names vary by guide and release, so each cell marks what to confirm against the current authentik GitHub guide before you configure anything.

Field	SAML SSO (organization model)	Enterprise Managed Users with SCIM
Login identifier (NameID)	Confirm the NameID format and the source attribute in the current guide, and match it to the GitHub account linked to each user	Usually the GitHub username comes from the IdP username; confirm the exact userName mapping in the EMU guide
Email address	Sent as an attribute; confirm the attribute name GitHub expects and that it matches a verified email on the user	Sent through SCIM emails; confirm the primary email field and that it uses the enterprise email domain
Display name	Optional for login; confirm whether the guide maps given and family name attributes	Mapped through SCIM name fields; confirm givenName and familyName handling in the guide
Group membership	Sent in a groups attribute only if you enable it; GitHub does not create teams from SAML groups alone	Groups can be pushed through SCIM; confirm whether group-to-team mapping is supported in the EMU guide before relying on it
Team assignment	Assigned manually or by a separate process inside GitHub, since SAML login does not place users into teams	Team membership follows SCIM group provisioning, so the authentik group name must match the planned GitHub team
Organization role	Owner or member is set in GitHub; confirm whether any role mapping is available in your guide version	Confirm which authentik group, if any, maps to the enterprise owner role before first sync
Deprovisioning	Removing the user from authentik blocks new SAML logins, but the GitHub membership remains until removed	SCIM deactivation removes the managed user; confirm the expected behavior for existing repository access

Repository, secrets and migration effects of changing identity models

Switching a GitHub Enterprise Cloud organization to SAML SSO through authentik, or moving to Enterprise Managed Users, changes how people sign in and which account owns their activity. It does not move repository content. Git history, branches and pull requests stay where they are, but GitHub Actions secrets are returned by the REST API only by name, never by their encrypted values, so every secret must be re-created on any platform you move to. Plan an inventory of secret names per repository, environment and organization before you change the identity model, and confirm with your CI owners which secrets are read-only tokens, deploy keys or cloud credentials that also need rotation in the target system.

If the identity change is bundled with a platform move, the organization migrations API is the tool to inspect, not a backup. It creates a migration archive of selected repositories with Git data, metadata, attachments and releases, and each of those parts can be excluded. Archives are deleted automatically after seven days, so any archive you generate must be downloaded and stored under your own retention rules within that window. Confirm with GitHub which data your archive will omit, such as secrets, and record that gap in the cutover plan.

Repository size limits also shape the plan. GitHub's repository limits documentation recommends keeping the .git folder under 10 GB and single objects under 1 MB, enforces a 100 MB maximum file size and a 2 GB maximum push size. Large binary assets, vendored dependencies or old release artifacts tend to surface during an identity cutover when developers push again through new accounts. Run a size audit before the cutover, decide which large files move to external storage, and check that the target platform enforces equal or compatible limits. Rate limits, such as the 5,000 requests per hour for personal access tokens and 15,000 per hour for GitHub Enterprise Cloud apps, also matter for bulk migration scripts.

Hardening the authentik to GitHub trust relationship

Once authentik and GitHub Enterprise Cloud trust each other, every sign-in and every provisioned account depends on a small set of secrets and administrator roles. The cards below cover the controls that keep that trust narrow, and each one ends with what your own team must confirm before go-live.

Signing certificate handling and rotation

The SAML signing certificate that authentik presents is the item GitHub trusts to vouch for every login. Confirm who can export the private key, where it is stored, and which certificate expiry date is tracked in your change calendar. Plan the rotation as a paired change: add the new certificate on the GitHub side, test a sign-in, then retire the old one so logins do not fail at expiry.

Restricting administrators on both sides

Two administrator populations hold the keys: authentik administrators who can edit the GitHub application and its mappings, and GitHub organization owners who can change SAML settings. Confirm that each group is small, named and separate, and that a change to either side is reviewed by someone on the other. A single person who controls both ends can redirect logins without anyone noticing.

SCIM token storage and rotation

If you use Enterprise Managed Users, the SCIM token lets authentik create, change and disable GitHub accounts. Store it in your secrets manager rather than in a provider configuration that many administrators can read, and confirm who can regenerate it. Record a rotation procedure that updates authentik and invalidates the old token in the same window, so provisioning does not silently stop.

Break-glass owner accounts

Enforcing SAML SSO means that a broken identity provider can lock out the whole organization. Confirm that at least one named owner account exists with a recovery method that does not depend on authentik, and that its credentials are stored under dual control. Test the recovery path before enforcement is turned on, and document who may use it and how each use is recorded.

Audit logging on both sides

Sign-in events, SAML configuration changes and provisioning actions must be visible from authentik and from the GitHub organization audit log. Confirm where each log is retained, who can read it, and that the two sources can be correlated by user and time. Check that your authentik logs leave the host through your log pipeline, because the default location may not survive an incident investigation.

Common SSO and provisioning failures and their fixes

This table lists the failures teams most often hit when enforcing SAML SSO for GitHub Enterprise Cloud through authentik, with the likely cause and the fix for each. Use it as a checklist during pilot testing and again after any certificate rotation, enforcement change or bulk provisioning run.

Failure	Likely cause	Fix
Sign-in fails after certificate rotation	The signing certificate on the authentik SAML provider was replaced, but GitHub still trusts the old certificate in the organization SAML settings.	Export the new certificate from the authentik provider, upload it in the GitHub SAML configuration, then test with a non-admin account before enforcing again.
Sign-in loop between GitHub and authentik	The NameID format or the email value sent by authentik does not match the verified email of the GitHub user, so GitHub cannot link the session to an account.	Compare the NameID and attributes in a SAML trace against the user's verified email on GitHub, correct the authentik property mapping, and confirm the user's email matches in both systems.
Users missing from the organization after enforcement	Members who never completed SAML linking were removed or blocked when enforcement was turned on, or they signed in with a personal account that is not tied to the organization.	Before enforcing, ask each member to sign in through the SSO link and confirm membership. Re-invite users who were removed, and keep a list of owners who can recover access.
SCIM deprovisioning does not remove access	The leaver was deactivated in authentik but the SCIM operation did not reach GitHub, the user is still provisioned in an EMU group, or the account is not in the scope of the provisioning app.	Check the authentik provisioning log for the deactivate request, confirm the user is in the bound group, and verify the user is removed in GitHub. Test deprovisioning with a pilot account.
Provisioning stalls during bulk onboarding	A large sync sends many API calls in a short period, and the request budget for the token or GitHub app is exhausted.	Stagger large group assignments, and review the rate limits for personal access tokens (5,000 requests per hour) and GitHub Enterprise Cloud apps (15,000 requests per hour) per the GitHub Actions limits documentation. Retry after the window resets.
Enforcement blocks an owner or service account	Enforcement applies to all members, including automation accounts that have no interactive SSO session.	Identify automation and break-glass accounts before enforcement, and confirm the approach for each with GitHub documentation and your identity team. Document the recovery path.

Questions teams ask before connecting GitHub Enterprise Cloud to authentik

Can I use SAML SSO and Enterprise Managed Users together?

Not on the same organization. SAML SSO for a GitHub Enterprise Cloud organization is a sign-in layer over accounts that users already own. Enterprise Managed Users (EMU) is a separate model in which GitHub creates and owns the accounts, with identities supplied by the identity provider and kept current through SCIM. authentik publishes separate guides for each, so the first decision is which model fits your organization. If you choose EMU, the SAML and SCIM setup replaces the organization SAML guide rather than running beside it. Confirm the current EMU rules with GitHub before you commit, because account ownership and the switch from personal accounts have consequences that are hard to reverse.

What does GitHub Enterprise Cloud cost per user?

GitHub's pricing page lists Team at $4 and Enterprise at $21 per user per month. Enterprise is the tier that covers the organization-level SAML SSO and EMU features this integration depends on, and you should confirm the current feature matrix on that page before purchasing. The GitHub subscription is a recurring cost paid to GitHub and is separate from authentik's own licensing. authentik's Open Source edition is free, while its Enterprise edition is priced per user on the authentik pricing page. Ask your procurement team to model both subscriptions for your headcount, including external collaborators, because the per-user basis changes the total as your population changes.

What drives the effort of a GitHub and authentik integration?

Four factors shape most of the work. The number of organizations matters, because each one needs its own SSO configuration and testing. The state of existing accounts matters, since personal accounts that already hold repositories must be matched to corporate identities or migrated, and mismatched emails cause lockouts. The need for SCIM matters because automated provisioning and deprovisioning add identity mapping, group design and offboarding tests. The data residency choice matters, because GitHub Enterprise Cloud with data residency runs on a dedicated GHE.com subdomain in specific regions and does not offer public repositories or certain Copilot features. Ask a partner to scope each factor separately in a written quote.

How long does a GitHub SAML or EMU integration take?

No duration is fixed here, and the timeline depends on the factors above, the state of your identity source and your change windows. A single organization with clean identities and no SCIM typically moves faster than several organizations with existing personal accounts and automated provisioning. Plan time for a test organization, a pilot group of users, a rollback path and a cutover that developers can absorb. Treat the schedule as an output of the written scope, and ask any partner to name the dependencies it assumes, such as access to the identity provider administrator role, a GitHub enterprise owner and a test tenant.

What do we need to provide before the work starts?

Prepare the people and access the work requires. You need an authentik administrator who can create applications, providers and property mappings, and a GitHub enterprise owner who can change SSO and provisioning settings. You also need a list of organizations, a decision on EMU or SAML SSO, an inventory of personal accounts with repositories and Actions secrets, and a named contact for developer communication. Note that GitHub's REST API returns the names of Actions secrets but never their encrypted values, so secrets must be re-created on any new platform. Agree the test plan and cutover window in writing before any production change.

Can our own team set this up without a partner?

Yes, if your team has the authentik, identity and GitHub administration skills to run the configuration and testing. The authentik integration guides describe the steps, but the difficult parts are usually not in the guide: email matching, account ownership, provisioning rules and developer impact. Many teams do the first organization themselves and then ask for an outside review of the EMU or SCIM design. DeployOpen plans, implements, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with written deliverables. Decide the split of work before you start, and confirm who owns the production change and the rollback.

What happens to the integration when authentik is upgraded?

Each authentik upgrade can change providers, flows, outposts and database requirements, so the GitHub configuration must be retested after every planned upgrade. authentik's security policy lists 2026.5.x and 2026.8.x as supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. The 2025.10 release notes also warned of roughly 50% more PostgreSQL connections after upgrading. Plan a staging environment, check the release notes for the versions you cross, and keep a tested rollback. Ask your partner whether upgrade testing is covered by the scope or by a retainer.

Does data residency change the GitHub setup?

Yes. GitHub Enterprise Cloud with data residency runs on a dedicated GHE.com subdomain in EU (including Azure regions in Norway and Switzerland), Australia, US or Japan regions. Your identity provider URLs, SSO endpoints and developer login addresses must match the region you choose, and GHE.com does not offer public repositories or certain GitHub Copilot features. Confirm the region and the feature limits with GitHub before the design is locked, because moving to a different region later is a migration rather than a setting change. Ask your partner to document the chosen subdomain in the runbook.

How DeployOpen scopes and delivers this integration

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For this integration, that means the authentik deployment, the SAML application for your GitHub Enterprise Cloud organization, the enforcement settings, and the runbook your administrators use afterward all run in your cloud accounts, data centers or network. DeployOpen does not host authentik for you, and it does not operate your GitHub organization on your behalf unless that work is written into the scope.

Most engagements are fixed-scope. Before any work starts, DeployOpen and your organization agree in writing on which model applies (organization SAML SSO or Enterprise Managed Users with SCIM), which identity sources and groups are in scope, which authentik version and deployment method are used, who approves the GitHub-side changes, and what the handover contains. A quote follows from that written scope, so the questions to settle first are the number of organizations and enterprise accounts, the number of users and groups to map, whether developer access changes must be tested in a staging organization, and whether recovery and break-glass procedures are part of the deliverables. Ongoing support, upgrades and continuous testing are available as a retainer and are priced separately from the initial build.

DeployOpen prepares systems, configuration, documentation and evidence that your team can present to an auditor, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. If your organization needs assurance for a specific control, confirm with your assessor which evidence they expect, and ask DeployOpen to scope the collection of that evidence in the written agreement.

authentik and GitHub Enterprise Cloud SAML integration