Note: OpenID Connect (OIDC) and Conditional Access Policy (CAP) support for Enterprise Managed Users is only available for Azure AD.
When your enterprise uses OIDC SSO, GitHub will automatically use your IdP's conditional access policy (CAP) IP conditions to validate user interactions with GitHub, when members change IP addresses, and each time a personal access token or SSH key is used.
GitHub Enterprise Cloud supports CAP for any enterprise with managed users where OIDC SSO is enabled. GitHub Enterprise Cloud enforces your IdP's IP conditions but cannot enforce your device compliance conditions. Enterprise owners can choose to use this IP allow list configuration instead of GitHub Enterprise Cloud's IP allow list, and can do so once OIDC SSO is configured. For more information about IP allow lists, see "Restricting network traffic with an IP allow list" and "Managing allowed IP addresses for your organization."
GitHub sends the originating IP address to your IdP for validation against your CAP. To make sure actions and apps are not blocked by your IdP's CAP, you will need to make changes to your configuration.
Warning: If you use GitHub Enterprise Importer to migrate an organization from your GitHub Enterprise Server instance, make sure to use a service account that is exempt from Azure AD's CAP otherwise your migration may be blocked.
Actions that use a personal access token will likely be blocked by your IdP's CAP. We recommend that personal access tokens are created by a service account which is then exempted from IP controls in your IdP's CAP.
If you're unable to use a service account, another option for unblocking actions that use personal access tokens is to allow the IP ranges used by GitHub Actions. For more information, see "About GitHub's IP addresses."
When GitHub Apps and OAuth Apps sign a user in and make requests on that user's behalf, also known as a
user-to-server request, GitHub will send the IP address of the app's server to your IdP for validation. If the IP address of the app's server is not validated by your IdP's CAP, the request will fail.
When GitHub Apps call GitHub APIs acting either as the app itself or as an installation, these calls are not performed on behalf of a user - this is also known as a
server-to-server request. Since your IdP's CAP executes and applies policies to user accounts, these application requests cannot be validated against CAP and are always allowed through. For more information on GitHub Apps authenticating as themselves, see "Authenticating with GitHub Apps".
You can contact the owners of the apps you want to use, ask for their IP ranges, and configure your IdP's CAP to allow access from those IP ranges. If you're unable to contact the owners, you can review your IdP sign-in logs to review the IP addresses seen in the requests, then allow-list those addresses.
If you do not wish to allow all of the IP ranges for all of your enterprise's apps, you can also exempt installed GitHub Apps and authorized OAuth Apps from the IdP allow list. If you do so, these apps will continue working regardless of the originating IP address. For more information, see "Enforcing policies for security settings in your enterprise."