GitHub のアクセス管理機能（SSO・MFA・IP制限・監査ログ）

You can control and secure access to resources like repositories, issues, and pull requests within your enterprise's organizations by enforcing SAML single sign-on (SSO) through your identity provider (IdP).

Who can use this feature?

Enterprise owners can configure SAML SSO for an enterprise on GitHub.

Before following the steps in this article, make sure that your enterprise uses personal accounts. You can do so by checking whether your enterprise view has the "Users managed by ACCOUNT NAME" header bar at the top of the screen.

If you see this, your enterprise uses managed users and you must follow a different process to configure SAML single sign-on. See Configuring SAML single sign-on for Enterprise Managed Users.

Single sign-on (SSO) gives organization owners and enterprise owners a way to control and secure access to organization resources like repositories, issues, and pull requests.

If you configure SAML SSO, members of your organization will continue to sign into their personal accounts on GitHub.com. When a member accesses most resources within your organization, GitHub redirects the member to your IdP to authenticate. After successful authentication, your IdP redirects the member back to GitHub. For more information, see About authentication with single sign-on.

SAML SSO does not replace the normal sign-in process for GitHub. Unless you use Enterprise Managed Users, members will continue to sign into their personal accounts on GitHub.com, and each personal account will be linked to an external identity in your IdP.

After you enable SAML SSO, OAuth app and GitHub App authorizations may need to be revoked and reauthorized before they can access the organization. For more information, see Authorizing OAuth apps.

Supported identity providers

GitHub supports SAML SSO with IdPs that implement the SAML 2.0 standard. For more information, see the SAML Wiki on the OASIS website.

GitHub officially supports and internally tests the following IdPs for SAML.

Microsoft Active Directory Federation Services (AD FS)

Microsoft Entra ID (previously known as Azure AD)

For more information about connecting Microsoft Entra ID (previously known as Azure AD) to your enterprise, see Tutorial: Microsoft Entra SSO integration with GitHub Enterprise Cloud - Enterprise Account in Microsoft Docs.

GitHub does not test or validate identity provider (IdP) gallery applications for use in Government Cloud environments, including Microsoft Entra ID Government Cloud and Okta Government Cloud. Authentication and SCIM provisioning issues that involve gallery applications in these environments fall outside GitHub's scope of support.

Enforcing SAML single-sign on for organizations in your enterprise account

When you enforce SAML SSO for your enterprise, the enterprise configuration will override any existing organization-level SAML configurations. There are special considerations when enabling SAML SSO for your enterprise account if any of the organizations owned by the enterprise account are already configured to use SAML SSO. For more information, see Switching your SAML configuration from an organization to an enterprise account.

When you enforce SAML SSO for an organization, GitHub removes any members of the organization that have not authenticated successfully with your SAML IdP. When you require SAML SSO for your enterprise, GitHub does not remove members of the enterprise that have not authenticated successfully with your SAML IdP. The next time a member accesses the enterprise's resources, the member must authenticate with your SAML IdP.

For more detailed information about how to enable SAML using Okta, see Configuring SAML single sign-on for your enterprise using Okta.

Navigate to your enterprise. For example, from the Enterprises page on GitHub.com.

At the top of the page, click Settings.

Under Settings, click Authentication security.

Optionally, to view the current configuration for all organizations in the enterprise account before you change the setting, click View your organizations' current configurations.

Under "SAML single sign-on", select Require SAML authentication.

In the Sign on URL field, type the HTTPS endpoint of your IdP for single sign-on requests. This value is available in your IdP configuration.

Optionally, in the Issuer field, type your SAML issuer URL to verify the authenticity of sent messages.

Under Public Certificate, paste a certificate to verify SAML responses. This is the public key corresponding to the private key used to sign SAML responses.

GitHub does not enforce the expiration of this SAML IdP certificate. This means that even if this certificate expires, your SAML authentication will continue to work. However, if your IdP administrator regenerates the SAML certificate, and you don't update it on the GitHub side, users will encounter a digest mismatch error during SAML authentication attempts due to the certificate mismatch. See Error: Digest mismatch.

To find the certificate, refer to the documentation for your IdP. Some IdPs call this an X.509 certificate.

Under your public certificate, to the right of the current signature and digest methods, click .

Select the Signature Method and Digest Method dropdown menus, then click the hashing algorithm used by your SAML issuer.

Before enabling SAML SSO for your enterprise, to ensure that the information you've entered is correct, click Test SAML configuration . This test uses Service Provider initiated (SP-initiated) authentication and must be successful before you can save the SAML settings.

To ensure you can still access your enterprise on GitHub if your IdP is unavailable in the future, click Download, Print, or Copy to save your recovery codes. For more information, see Downloading your enterprise account's single sign-on recovery codes.

Who can use this feature?

As of March 2023, GitHub required all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA). If you were in an eligible group, you would have received a notification email when that group was selected for enrollment, marking the beginning of a 45-day 2FA enrollment period, and you would have seen banners asking you to enroll in 2FA on GitHub.com. If you didn't receive a notification, then you were not part of a group required to enable 2FA, though we strongly recommend it.

For more information about the 2FA enrollment rollout, see this blog post.

About two-factor authentication for organizations

Two-factor authentication (2FA) is an extra layer of security used when logging into websites or apps. You can require all members, outside collaborators, and billing managers in your organization to enable two-factor authentication on GitHub. For more information about two-factor authentication, see Securing your account with two-factor authentication (2FA).

You can also require two-factor authentication for organizations in an enterprise. For more information, see Enforcing policies for security settings in your enterprise.

Some of the users in your organization may have been selected for mandatory two-factor authentication enrollment by GitHub, but it has no impact on how you enable the 2FA requirement for your organization.

When you require use of two-factor authentication for your organization, members and billing managers who do not use 2FA will not be able to access your organization's resources until they enable 2FA on their account. They will retain membership even without 2FA, including consuming seats in your organization.

When you require use of two-factor authentication for your organization, outside collaborators who do not use 2FA will be removed from the organization and lose access to its repositories. They will also lose access to their forks of the organization's private repositories. You can reinstate their access privileges and settings if they enable 2FA for their personal account within three months of their removal from your organization. For more information, see Reinstating a former member of your organization.

You will also need to enable two-factor authentication for unattended or shared access accounts that are outside collaborators, such as bots and service accounts. If you do not configure 2FA for these unattended outside collaborator accounts after you've enabled required 2FA, the accounts will be removed from the organization and lose access to their repositories. For more information, see Managing bots and service accounts with two-factor authentication.

If an outside collaborator disables two-factor authentication for their personal account after you've enabled required 2FA, they will automatically be removed from the organization.

If you're the sole owner of an organization that requires two-factor authentication, you won't be able to disable 2FA for your personal account without disabling required 2FA for the organization.

Before you can require organization members, outside collaborators, and billing managers to use two-factor authentication, you must enable 2FA for your account. For more information, see Securing your account with two-factor authentication (2FA).

Before you require use of two-factor authentication, we recommend notifying organization members, outside collaborators, and billing managers and asking them to set up 2FA for their accounts. You can see if members and outside collaborators already use 2FA. For more information, see Viewing whether users in your organization have 2FA enabled.

In the upper-right corner of GitHub, click your profile picture, then click Organizations.

Select an organization by clicking on it.

Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

In the "Security" section of the sidebar, click Authentication security.

Under "Two-factor authentication", select Require two-factor authentication for everyone in your organization, then click Save.

If prompted, read the information about members and outside collaborators who will be removed from the organization.

To confirm the change, click Confirm.

Requiring secure methods of two-factor authentication in your organization

Alongside requiring two-factor authentication, you can require that organization members, billing managers, and outside collaborators use secure methods of 2FA exclusively. Secure two-factor methods are passkeys, security keys, authenticator apps, and the GitHub mobile app. Users who do not have a secure method of 2FA configured, or who have any insecure method (such as SMS) configured, will be prevented from accessing organization resources.

Before you require secure methods of two-factor authentication, we recommend notifying organization members, outside collaborators, and billing managers: you should instruct them to set up secure 2FA for their accounts and then remove insecure methods of 2FA (including SMS). On each organization's People page, you can see if members and outside collaborators already use secure methods of 2FA exclusively. For more information, see Viewing whether users in your organization have 2FA enabled.

If prompted, read the information about how user access to organization resources will be affected by requiring secure 2FA methods. To confirm the change, click Confirm.

Who can use this feature?

Requiring two-factor authentication is available to organizations on a GitHub Free or GitHub Team plan, as well as organizations on GitHub Enterprise Cloud or GitHub Enterprise Server. With GitHub Enterprise Cloud, this feature is unavailable for organizations in an enterprise with managed users.

As of March 2023, GitHub required all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA). If you were in an eligible group, you would have received a notification email when that group was selected for enrollment, marking the beginning of a 45-day 2FA enrollment period, and you would have seen banners asking you to enroll in 2FA on GitHub.com. If you didn't receive a notification, then you were not part of a group required to enable 2FA, though we strongly recommend it.

For more information about the 2FA enrollment rollout, see this blog post.

About two-factor authentication for organizations

Two-factor authentication (2FA) is an extra layer of security used when logging into websites or apps. You can require all members, outside collaborators, and billing managers in your organization to enable two-factor authentication on GitHub. For more information about two-factor authentication, see Securing your account with two-factor authentication (2FA).

You can also require two-factor authentication for organizations in an enterprise. For more information, see Enforcing policies for security settings in your enterprise.

Some of the users in your organization may have been selected for mandatory two-factor authentication enrollment by GitHub, but it has no impact on how you enable the 2FA requirement for your organization.

When you require use of two-factor authentication for your organization, members and billing managers who do not use 2FA will not be able to access your organization's resources until they enable 2FA on their account. They will retain membership even without 2FA, including consuming seats in your organization.

When you require use of two-factor authentication for your organization, outside collaborators who do not use 2FA will be removed from the organization and lose access to its repositories. They will also lose access to their forks of the organization's private repositories. You can reinstate their access privileges and settings if they enable 2FA for their personal account within three months of their removal from your organization. For more information, see Reinstating a former member of your organization.

You will also need to enable two-factor authentication for unattended or shared access accounts that are outside collaborators, such as bots and service accounts. If you do not configure 2FA for these unattended outside collaborator accounts after you've enabled required 2FA, the accounts will be removed from the organization and lose access to their repositories. For more information, see Managing bots and service accounts with two-factor authentication.

If an outside collaborator disables two-factor authentication for their personal account after you've enabled required 2FA, they will automatically be removed from the organization.

If you're the sole owner of an organization that requires two-factor authentication, you won't be able to disable 2FA for your personal account without disabling required 2FA for the organization.

Before you can require organization members, outside collaborators, and billing managers to use two-factor authentication, you must enable 2FA for your account. For more information, see Securing your account with two-factor authentication (2FA).

Before you require use of two-factor authentication, we recommend notifying organization members, outside collaborators, and billing managers and asking them to set up 2FA for their accounts. You can see if members and outside collaborators already use 2FA. For more information, see Viewing whether users in your organization have 2FA enabled.

In the upper-right corner of GitHub, click your profile picture, then click Organizations.

Select an organization by clicking on it.

Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

In the "Security" section of the sidebar, click Authentication security.

Under "Two-factor authentication", select Require two-factor authentication for everyone in your organization, then click Save.

If prompted, read the information about members and outside collaborators who will be removed from the organization.

To confirm the change, click Confirm.

If any outside collaborators are removed from the organization, we recommend sending them an invitation that can reinstate their former privileges and access to your organization. They must enable two-factor authentication before they can accept your invitation.

Requiring secure methods of two-factor authentication in your organization

Alongside requiring two-factor authentication, you can require that organization members, billing managers, and outside collaborators use secure methods of 2FA exclusively. Secure two-factor methods are passkeys, security keys, authenticator apps, and the GitHub mobile app. Users who do not have a secure method of 2FA configured, or who have any insecure method (such as SMS) configured, will be prevented from accessing organization resources.

Under "Two-factor authentication", select Require two-factor authentication for everyone in your organization and Only allow secure two-factor methods, then click Save.

Without Enterprise Managed Users, the audit log only includes events related to the enterprise account and the organizations within it.

Someone was removed from the credit section of a security advisory.

business.audit_log_export

An export of the enterprise audit log was created. If the export included a query, the log will list the query used and the number of audit log entries matching that query.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, actor_is_bot, created_at, operation_type, query_phrase

external_group.scim_api_failure

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, actor_is_bot, api_request_body, created_at, large_group_warning, message, oauth_application_id, operation_type, query_string, request_method, route, scim_group_id, status_code, url_path, user_programmatic_access_name

REST API endpoints for SCIM

external_group.scim_api_success

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, actor_is_bot, api_request_body, created_at, large_group_warning, oauth_application_id, operation_type, query_string, request_method, route, scim_group_id, status_code, url_path

external_group.unlink

An external group was unlinked to a GitHub team.

external_group.update

An external group was updated.

external_group.update_display_name

An external group's display name was updated.

external_identity

external_identity.deprovision

An external identity was deprovisioned, suspending the linked GitHub user.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, actor_is_agent, actor_is_bot, created_at, oauth_application_id, operation_type, scim_user_id

external_identity.provision

An external identity was created and linked to a GitHub user.

external_identity.scim_api_failure

Failed external identity SCIM API request.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, actor_is_bot, api_request_body, created_at, message, oauth_application_id, operation_type, query_string, request_method, route, scim_user_id, status_code, url_path, user_programmatic_access_name

external_identity.scim_api_success

Successful external identity SCIM API request. Excludes GET API requests.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, actor_is_bot, api_request_body, created_at, oauth_application_id, operation_type, query_string, request_method, route, scim_user_id, status_code, url_path

external_identity.update

An external identity was updated.

Note: Git events have special access requirements and retention policies that differ from other audit log events. For GitHub Enterprise Cloud, access Git events via the REST API only with 7-day retention. For GitHub Enterprise Server, Git events must be enabled in audit log configuration and are not included in search results.

A repository was cloned. This event is not available in the web interface, only via the REST API, audit log streaming, or JSON/CSV exports.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, external_id, repository_public, transport_protocol, transport_protocol_name

Changes were fetched from a repository. This event is not available in the web interface, only via the REST API, audit log streaming, or JSON/CSV exports.

hook.active_changed

A hook's active status was updated.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, active, active_was, actor_is_agent, actor_is_bot, created_at, events, hook_id, integration, name, oauth_application_id, operation_type, public_repo, sponsors_listing_id, user_programmatic_access_name

A hook's configuration was changed.

@timestamp, _document_id, action, actor, actor_id, business, business_id, hashed_token, org, org_id, programmatic_access_type, repo, repo_id, repository, repository_id, request_access_security_header, request_id, token_id, token_scopes, user, user_id, user_agent, active, actor_is_agent, actor_is_bot, created_at, events, hook_id, integration, name, oauth_application_id, operation_type, public_repo, sponsors_listing_id, user_programmatic_access_name