> 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.2/instance-administration/authentication/overview.md).

# Overview

SonarQube Server 10.2 can delegate authentication via HTTP Headers, GitHub Authentication, GitLab Authentication, Bitbucket Cloud Authentication, SAML, or LDAP.

{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 10.2 documentation. For a list of all 10.2 pages, see the [SonarQube Server 10.2 page index](https://2995682738-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9JA8mmyfC7QWzIoP9Meh%2Fuploads%2FQfpu1DTKUwWYFCaHqyVO%2Fsonarqube-server-10.2-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.2 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}

SonarQube Server comes with its own user database, as well as the ability to delegate authentication via protocols and providers. Each method offers:

* user identity management
* authentication
* user and group provisioning
* group synchronization (optional for JIT provisioning)

## Supported authentication methods <a href="#supported-authentication-methods" id="supported-authentication-methods"></a>

You can use one of the following authentication methods to allow the same authentication between SonarQube Server and your authentication system:

* HTTP header
* LDAP
* SAML with:
  * Azure AD
  * Keycloak
  * Okta
* GitHub
* Bitbucket Cloud
* GitLab

{% hint style="warning" %}
Using an authentication method that is not supported by SonarQube Server can lead to a security breach. Sonar declines any responsibility in this regard.
{% endhint %}

## User, group and permissions provisioning <a href="#user-and-group-provisioning" id="user-and-group-provisioning"></a>

There are two ways of provisioning users and groups in SonarQube Server: Just-in-Time (JIT) and automatic provisioning.

In both cases, permissions themselves are still managed in SonarQube Server. The most effective way to handle permissions is to give permissions to groups (vs. individual users) directly and/or use [Security](/sonarqube-server/10.2/instance-administration/security.md), then manage group membership using one of the provisioning methods.

### Just-in-Time provisioning <a href="#justintime-provisioning" id="justintime-provisioning"></a>

This is the default provisioning method. User accounts are created in SonarQube Server when users log in for the first time. Groups must be manually created by administrators. However, memberships are automatically updated at each user login.

**Group synchronization**

When using group synchronization, the following details apply regardless of which delegated authentication method is used:

* Memberships in a group are synchronized only if a group with the same name exists in SonarQube Server. Administrators must first [Security](/sonarqube-server/10.2/instance-administration/security.md).
* Memberships in synchronized groups override any membership configured locally in SonarQube Server. When enabling group synchronization, *manually added* group memberships get reset.
* Memberships in the default built-in *sonar-users* group remain even if the group does not exist in the identity provider.

For specific details about group synchronization, refer to each provider’s group synchronization section.

{% hint style="info" %}
When group synchronization is configured, group memberships can only be managed from the delegated authentication source, and the user’s groups are re-fetched with each login. It is not possible to use both manual group memberships and group synchronization (via your ALM integration) for the same user.
{% endhint %}

### Automatic provisioning <a href="#automatic-provisioning" id="automatic-provisioning"></a>

Users and groups are automatically synchronized using the identity provider as the source of truth.

The main benefit compared to Just-in-Time provisioning is that user and group deprovisioning also happens automatically and does not require administrator intervention.

SonarQube Server enables automatic provisioning for the following providers:

* [SCIM provisioning with Azure AD](/sonarqube-server/10.2/instance-administration/authentication/saml/scim/scim-provisioning-with-azure-ad.md) and [SCIM provisioning with Okta](/sonarqube-server/10.2/instance-administration/authentication/saml/scim/scim-provisioning-with-okta.md) (through the [Overview](/sonarqube-server/10.2/instance-administration/authentication/saml/scim/overview.md)): Group and user synchronization.
* [GitHub](/sonarqube-server/10.2/instance-administration/authentication/github.md): Group and user synchronization. Project permissions are also synchronized and deprovisioned automatically.

## Revoking tokens for deactivated users <a href="#revoking-tokens-for-deactivated-users" id="revoking-tokens-for-deactivated-users"></a>

When SonarQube Server authentication is delegated to an external identity provider, deactivating a user on the identity provider side does not remove any tokens associated with the user on the SonarQube Server side. We recommend deactivating the user in SonarQube Server at **Administration** > **Security** > **Users** by selecting **Deactivate** from the drop-down menu to ensure tokens associated with that user can no longer be used.

## Delete users’ personal information <a href="#delete-users-personal-information" id="delete-users-personal-information"></a>

SonarQube Server offers the possibility to anonymize the data of deactivated users. This comes in handy when you want to ensure that the personal data of deactivated users is not retained, for example, for legal compliance.

You can delete a user’s personal information by following the steps listed above to revoke tokens for any deactivated users and select the checkbox titled **Delete user’s personal information**.

You can also delete personal information using the API. First, the user needs to be deactivated, then an admin can use the web service `/api/users/anonymize` and pass to it the login of a deactivated user to replace all personal data of the user with anonymized data. Note that the admin is able to retrieve the logins of deactivated users by using `/api/users/search` endpoint with the appropriate parameter.

This feature has the following limitations:

* Deleting the personal information of a user will change their login, making it impossible to reactivate the user by recreating a user with the old login.
* The user’s login may still be stored in issue changelogs and the user’s login, name, and email address may still be stored in audit entries. Audit entries are purged by default after 30 days.
* Deleted users may still appear in the list of authors and other locations due to SCM data.
* Some columns in the database may contain parts of the user’s login if the user was created before the instance was upgraded to SonarQube Server 8.3.


---

# 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.2/instance-administration/authentication/overview.md?ask=<question>&goal=<user_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.
