Skip to main content

About authentication for your enterprise

You can choose how people authenticate to access your enterprise's resources on GitHub Enterprise Cloud.

About authentication for your enterprise

Enterprise owners on GitHub Enterprise Cloud can control the requirements for authentication and access to the enterprise's resources.

You can choose to allow members to create and manage user accounts, or your enterprise can create and manage accounts for members with Enterprise Managed Users. If you allow members to manage their own accounts, you can also configure SAML authentication to both increase security and centralize identity and access for the web applications that your team uses.

After learning more about these options, to determine which method is best for your enterprise, see "Identifying the best authentication method for your enterprise."

Authentication methods for GitHub Enterprise Cloud

The following options are available for account management and authentication on GitHub Enterprise Cloud.

Authentication through

By default, each member must create a personal account on You grant access to your enterprise, and the member can access your enterprise's resources after signing into the account on The member manages the account, and can contribute to other enterprises, organizations, and repositories on

Authentication through with additional SAML access restriction

If you configure additional SAML access restriction, each member must create and manage a personal account on You grant access to your enterprise, and the member can access your enterprise's resources after both signing into the account on and successfully authenticating with your SAML identity provider (IdP). The member can contribute to other enterprises, organizations, and repositories on using their personal account. For more information about requiring SAML authentication for all access your enterprise's resources, see "About SAML for enterprise IAM."

You can choose between configuring SAML at the enterprise level, which applies the same SAML configuration to all organizations within the enterprise, and configuring SAML separately for individual organizations. For more information, see "AUTOTITLE."

Authentication with Enterprise Managed Users and federation

If you need more control of the accounts for your enterprise members on, you can use Enterprise Managed Users. With Enterprise Managed Users, you provision and manage accounts for your enterprise members on using your IdP. Each member signs into an account that you create, and your enterprise manages the account. Contributions to the rest of are restricted. For more information, see "About Enterprise Managed Users."

Identifying the best authentication method for your enterprise

Both SAML SSO and Enterprise Managed Users increase security for your enterprise's resources. Enterprise Managed Users additionally allows you to control the user accounts for your enterprise members and restricts what the accounts are able to do. However, those restrictions may be unacceptable for your enterprise if they obstruct your developers' workflows.

To determine whether your enterprise would benefit more from SAML SSO or Enterprise Managed Users, ask yourself the following questions.

Do you want to control the user accounts for your users?

Enterprise Managed Users may be right for your enterprise if you don't want enterprise members to use their own personal accounts on to access your enterprise's resources.

With SAML SSO, developers create and manage their own personal accounts, and each account is linked to a SAML identity in your IdP. Enterprise Managed Users functions more like other familiar SSO solutions, as you will provision the accounts for your users. You can also ensure user accounts conform with your company identity, by controlling usernames and the email addresses associated with the accounts.

If you currently require your users to create a new account on to use with your enterprise only, Enterprise Managed Users might be right for you. However, SAML SSO may be a better option if using your IdP as the source of truth for your user and access management would add too much complexity. For example, perhaps your enterprise does not have an established process for onboarding new users in your IdP.

Which identity provider does your enterprise use?

Enterprise Managed Users is supported for a limited number of IdPs and requires SCIM, while SAML SSO offers full support for a larger number of IdPs, plus limited support for all IdPs that implement the SAML 2.0 standard, and does not require SCIM. For the list of supported IdPs for each option, see "About Enterprise Managed Users" and "About SAML for enterprise IAM."

You can use Enterprise Managed Users with an unsupported IdP only if you federate the unsupported IdP to a supported IdP to use as an integration point. If you wish to avoid this extra complexity, SAML SSO may be a better solution for you.

Do your developers work in public repositories, gists, or GitHub Pages sites?

To prevent enterprise members from accidentally leaking corporate-owned content to the public on, Enterprise Managed Users imposes strong restrictions on what users can do. For example, managed user accounts cannot create public repositories, gists of any visibility, or GitHub Pages sites that are visible outside the enterprise. For a full list of restrictions, see "About Enterprise Managed Users."

These restrictions are unacceptable for some enterprises. To determine whether Enterprise Managed Users will work for you, review the restrictions with your developers, and confirm whether any of the restrictions will hinder your existing workflows. If so, SAML SSO may be a better choice for your enterprise.

Do your developers rely on collaboration outside of your enterprise?

Managed user accounts can only contribute to repositories within your enterprise. If your developers must contribute to both repositories within and outside of your enterprise, including private repositories, Enterprise Managed Users may not be right for your enterprise. SAML SSO may be a better solution.

Some companies maintain repositories within an existing enterprise using SAML SSO on, and also create an enterprise with managed users. Developers who contribute to repositories owned by both enterprises from a single workstation must switch between the accounts on within a single browser, or use a different browser for each account. The developer may also need to customize the workstation's Git configuration to accommodate the two accounts. The complexity of this workflow can increase the risk of mistakenly leaking internal code to the public.

If you decide to create an enterprise with managed users but require that developers contribute to resources outside of the enterprise from a single workstation, you can provide support for switching between the accounts in a developer's local Git configuration. For more information, see "About Enterprise Managed Users."

Does your enterprise rely on outside collaborators?

With SAML SSO, you can give access to specific repositories to people who are not members of your IdP's directory, by using the outside collaborator role. This can be especially useful for collaborators that are external to your business, such as contractors. For more information, see "Adding outside collaborators to repositories in your organization."

With Enterprise Managed Users, the outside collaborator role does not exist. Your enterprise's resources can only be accessed by managed user accounts, which are always provisioned by your IdP. To give external collaborators access to your enterprise, you would have to use guest accounts in your IdP. If you're interested in Enterprise Managed Users, confirm with your developers whether this will hinder any of their existing workflows. If so, SAML SSO may be a better solution.

Can your enterprise tolerate migration costs?

If your enterprise is new to, SAML SSO and Enterprise Managed Users are equally easy to adopt.

If you're already using with developers managing their own user accounts, adopting Enterprise Managed Users requires migrating to a new enterprise account. For more information, see "About Enterprise Managed Users."

Although Enterprise Managed Users is free, the migration process may require time or cost from your team. Confirm that this migration process is acceptable to your business and your developers. If not, SAML SSO may be the better choice for you.

Deciding whether to configure SAML at the enterprise level or the organization level

If you decide to use SAML instead of Enterprise Managed Users, you must decide whether to configure SAML at the enterprise level or the organization level.

If some groups within your enterprise must use different SAML authentication providers to grant access to your resources on, configure SAML for individual organizations. You can implement SAML for your organizations over time by allowing users to gradually authenticate using SAML. Alternatively, you can require SAML authentication by a certain date. Organization members who do not authenticate using SAML by this date will be removed. For more information about organization-level SAML, see "About identity and access management with SAML single sign-on."

If you configure SAML at the organization level, members are not required to authenticate via SAML to access internal repositories. For more information about internal repositories, see "About repositories."

If you need to protect internal repositories or enforce a consistent authentication experience for every organization in your enterprise, you can configure SAML authentication for your enterprise account instead. The SAML configuration for your enterprise overrides any SAML configuration for individual organizations, and organizations cannot override the enterprise configuration. After you configure SAML for your enterprise, organization members must authenticate with SAML before accessing organization resources, including internal repositories.

SCIM is not available for enterprise accounts, and team synchronization is only available for SAML at the enterprise level if you use Azure AD as an IdP. For more information, see "Managing team synchronization for organizations in your enterprise."

Regardless of the SAML implementation you choose, you cannot add external collaborators to organizations or teams. You can only add external collaborators to individual repositories.

Further reading