> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/10.4/instance-administration/authentication/github.md).
# GitHub
In SonarQube Server 10.4, to allow users to log in with GitHub credentials, you must use a GitHub App.
{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 10.4 documentation. For a list of all 10.4 pages, see the [SonarQube Server 10.4 page index](https://2155789048-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FL4urx4YsPFYDefLTrxao%2Fuploads%2FlBlJSWAzuhYo7WEorlJX%2Fsonarqube-server-10.4-llms.txt?alt=media). For the whole site, see the [page index](https://docs.sonarsource.com/llms.txt) or the [full text](https://docs.sonarsource.com/llms-full.txt). For another version, replace 10.4 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}
To allow users to log in with GitHub credentials, you’ll need to register SonarQube Server as a GitHub App. This will also allow you to configure user, group, and permission provisioning.
{% hint style="warning" %}
Compatibility with OAuth apps is deprecated and will be removed in the future. The use of GitHub Apps is required for automatic provisioning of users and groups. If you’re still using an OAuth app, we recommend [registering SonarQube Server as a GitHub App](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app) and following the configuration steps below. For general information on the differences between OAuth apps and GitHub Apps, see the [GitHub documentation](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/differences-between-github-apps-and-oauth-apps).
{% endhint %}
## Register SonarQube Server as a GitHub App for authentication and provisioning
First, you’ll need to [register SonarQube Server as a GitHub App](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app). If you’ve already registered SonarQube Server as a GitHub App for pull request decoration (see [GitHub integration](/sonarqube-server/10.4/devops-platform-integration/github-integration.md)), you can also use it for user authentication and provisioning.
Configure the following settings in your GitHub App:
* **General** tab:
* **Homepage URL**: The public URL of your SonarQube Server instance. For example, `https://sonarqube.mycompany.com`. For security reasons, HTTP is not supported, and you must use HTTPS. The public URL is configured in SonarQube Server at **Administration** > **General** > **Server base URL**.
* **Redirect URI**: The public URL of your SonarQube Server instance. For example, `https://sonarqube.mycompany.com`.
* **Webhooks**: Deactivate the feature.
* **Permissions & events** tab:
| **Permission** | **Access** | **Comment** |
| ----------------------------------------- | ---------- | -------------------------------------------------------------------------------------------------------------- |
| Repository permissions > Administration | Read-only | Only for automatic provisioning.
After saving, the App owner must validate the permission change.
|
| Organization permissions > Administration | Read-only | Only for automatic provisioning.
After saving, the App owner must validate the permission change.
|
| Organization Permissions > Members | Read-only |
|
| Account permissions > Email addresses | Read-only |
|
* **Install App** tab: Click **Install** and validate the installation on each organization you need.
* During App creation, or under the **Advanced** tab, you can make the App *private* or *public*:
* Make it *private* if you only have one organization.
* Make it *public* if you have several organizations from where you need users to authenticate and/or be provisioned. Don’t forget to list those as allowed organizations in SonarQube Server (see below).
## Connecting your GitHub App to SonarQube Server
**Step 1**: In SonarQube Server, Navigate to **Administration** > **Configuration** > **General Settings** > **Authentication** > **GitHub** and click **Create configuration**.
**Step 2:** Fill the following fields with information from your GitHub App:
* * **Client ID**
* **Client Secret**
* **GitHub App ID**
* **Private Key**
**Step 3:** Fill the **API url** and **WEB url** fields as recommended by GitHub.\
\*\*\
Step 4:\*\* If your GitHub App is public, it is important that you enter the allowed organizations in the **Organizations** field.
{% hint style="warning" %}
For automatic provisioning, not entering the allowed organizations for a public App can let undesired users authenticate to your SonarQube Server instance, as public GitHub Apps can be installed by anyone.
When using Just-in-Time provisioning, if the allowed organizations are not entered, any user with a GitHub account can log in to the SonarQube Server instance, even if the GitHub App used for authentication is private.
{% endhint %}
**Step 5:** Click **Save** **configuration**.
## Choosing the provisioning method
Once you’ve created your GitHub configuration, you can choose how users and groups are provisioned to SonarQube Server. For an overview of the available provisioning methods, see [Overview](/sonarqube-server/10.4/instance-administration/authentication/overview.md).
**Step 1:** In SonarQube Server, from the **Authentication** > **GitHub** tab, click **Enable configuration**.
**Step 2:** Select a **provisioning method**. The available options are:
* * **Just-in-Time user and group provisioning (default)**:
* Users are provisioned when they authenticate through GitHub for the first time if the option **Allow users to sign up** is enabled.
* User information and group memberships are updated at each authentication.
* (Optional) You can synchronize GitHub teams with existing SonarQube Server groups of the same name with the **Synchronize teams as groups** option.
* **Automatic user, group, and permission provisioning** (starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/))
* Users and groups will be synchronized on an hourly basis. The first synchronization happens immediately when you enable the feature.
* Permissions are synchronized. See below for more information.
* You can check the status of the synchronization on this configuration page, in the box **Automatic user and group provisioning** box.
* If needed, you can manually trigger a synchronization by clicking **Synchronize now**.
* Groups in SonarQube Server are named after the GitHub organizations and teams’ names, ie. *Organization/Team.*
* The user’s email address is updated only when no address is set in SonarQube Server. Once a new address is set, it is only updated when the user authenticates.
**Step 3:** When you change a setting in your configuration, you can force SonarQube Server to check that it is valid by clicking **Test configuration.**
**Step 4:** Click **Save**.
From the login page, your users can now connect to SonarQube Server using their GitHub accounts by clicking the **Log in with GitHub** button.
## About user permission synchronization
With automatic provisioning, on top of users and groups, project-level group and user permissions are also synchronized from GitHub. Synchronization happens regularly, and it automatically adds or removes permissions from SonarQube Server.
As part of permission synchronization, you can synchronize the visibility of your projects by enabling the **Provision project visibility** option.
* When enabled, your SonarQube Server project’s visibility will match the corresponding GitHub repository’s visibility.
* When disabled, your SonarQube Server project’s visibility will be set to private, regardless of the GitHub repository’s visibility.
For all GitHub-managed users, permissions can no longer be edited on SonarQube Server GitHub projects. Changes of permissions are handled directly in GitHub.
### Permission mapping
SonarQube Server applies a default permission mapping that covers most use cases. If you have more advanced needs, you can customize this mapping so that each GitHub base role has exactly the SonarQube Server permissions you want. You can also configure permission mapping for GitHub custom roles.
To do this, click on the **Edit mapping** button in the section related to automatic provisioning.
Here is the default permission mapping. The first column lists the GitHub base role, and the first row lists the SonarQube Server permissions.
{% hint style="info" %}
**Known limitation (GitHub Enterprise only):** When a nested team has a custom role that extends the same base role as its parent team’s custom role, the nested team will use its parent’s custom role instead of its own.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sonarsource.com/sonarqube-server/10.4/instance-administration/authentication/github.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.