Authentification¶

Enregistrement utilisateur¶

La configuration par défaut est d’utiliser python-social-auth, un formulaire web pour gérer les inscriptions de nouveaux utilisateurs. Après confirmation de son e-mail, on peut contribuer et s’authentifier en utilisant des services tiers.

Vous pouvez aussi désactiver les inscriptions de nouveaux utilisateurs en utilisant REGISTRATION_OPEN.

Le nombre de tentatives d’authentification est sujet à Limite de requêtes.

Serveurs d’authentification¶

Weblate s’appuie sur Django pour l’authentification. Cela comprend l’authentification intégrée basée sur le mot de passe, l’authentification sociale, et les serveurs d’authentification tiers pour Django.

Utiliser l’authentification intégrée de Django signifie que vous pouvez importer la base de données des utilisateurs d’autres projets basés sur Django (voir Migrating from Pootle).

Voir aussi

Paramètres d’authentification décrit comment configurer l’authentification sur l’image Docker officielle.

Teams from identity providers¶

Ajouté dans la version 2026.10.1.

Weblate can synchronize selected teams from external group memberships or application roles during social authentication. The default native and Docker pipelines include synchronization after authentication checks and two-factor authentication. Extraction and assignment are disabled until configured. If you use a custom authentication pipeline, place social_core.pipeline.user.sync_groups after all authentication checks, including weblate.legal.pipeline.tos_confirm when terms acceptance is enabled.

Map external identifiers to lists of existing Weblate team IDs. Find team IDs in the administration interface URL or the teams REST API. Names can repeat across project and workspace scopes, so they are not used as mapping targets.

For Microsoft Entra ID, prefer application roles:

SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_KEY = "roles"
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_MAP = {
    "Weblate.Translator": [42],
    "Weblate.Reviewer": [43],
}

Configure the provider to issue these roles. Group identifiers can instead be selected with GROUPS_KEY = "groups". Group overage causes authentication to fail; Weblate does not retrieve memberships from Microsoft Graph. Restrict the trusted tenant and issuer before granting permissions, especially when using a common Azure endpoint.

For generic OpenID Connect or Keycloak, configure a literal claim name:

SOCIAL_AUTH_OIDC_GROUPS_KEY = "groups"
SOCIAL_AUTH_OIDC_GROUPS_MAP = {"translators": [42]}

SOCIAL_AUTH_KEYCLOAK_GROUPS_KEY = "groups"
SOCIAL_AUTH_KEYCLOAK_GROUPS_MAP = {"/organization/reviewers": [43]}

For GitLab, explicitly enable membership retrieval:

SOCIAL_AUTH_GITLAB_GROUPS_ENABLED = True
SOCIAL_AUTH_GITLAB_GROUPS_MAP = {"organization/translators": [42]}

Enabling retrieval automatically requests read_api unless read_api or api is already requested. Enable the corresponding permission in the GitLab OAuth application settings alongside read_user.

GitLab uses full group paths by default. Use stable numeric group IDs instead when paths might change or be reused:

SOCIAL_AUTH_GITLAB_GROUPS_IDENTIFIER = "id"
SOCIAL_AUTH_GITLAB_GROUPS_MAP = {"12345": [42]}

For SAML, add the group attribute and mapping to each existing entry in SOCIAL_AUTH_SAML_ENABLED_IDPS:

SOCIAL_AUTH_SAML_ENABLED_IDPS["company"].update(
    {
        "attr_groups": "https://example.com/claims/groups",
        "groups_map": {"translators": [42]},
        "allow_groups": ["translators", "reviewers"],
    }
)

All targets in a mapping become provider-managed teams. Authentication adds desired memberships and removes obsolete managed memberships. Unrelated teams and existing membership language restrictions are preserved. Changes are recorded in the audit log. Manual membership in a managed team is subject to replacement at the next authentication. A team may be managed by only one configured provider or SAML IdP; conflicting mappings and nonexistent teams cause errors before memberships change. No teams are created automatically.

A missing configured claim fails authentication. When a provider omits claims for users without assignments, explicitly enable its SOCIAL_AUTH_<BACKEND>_GROUPS_MISSING_AS_EMPTY setting. SAML uses groups_missing_as_empty in the IdP entry. An empty membership list removes all provider-managed memberships. An empty GROUPS_MAP disables assignment.

Login restrictions are independent of assignment. Configure SOCIAL_AUTH_<BACKEND>_ALLOW_GROUPS to require membership in any listed external group or role. Unknown identifiers grant nothing, but do not reject login unless an allow list is configured. Existing CAS allow lists require no new settings or pipeline entries.

Synchronization applies to login, registration, and authentication-method linking. Password reset and account removal do not synchronize teams. Updates occur only during authentication; this does not deactivate accounts or revoke access in the background. Synchronization does not store external membership snapshots.

In Docker installations, use Configuration beyond environment variables to supply these Python settings; there are no dedicated environment variables for team mappings.

Voir aussi

External groups

S’authentifier par mot de passe¶

Le fichier par défaut settings.py est fourni avec un ensemble raisonnable de AUTH_PASSWORD_VALIDATORS qui assure que les mauvais mots de passe ne sont pas autorisés. Vous pouvez adapter ces valeurs pour qu’elles soient conformes à votre politique des mots de passe.

De plus vous pouvez aussi installer django-zxcvbn-password-validator qui donne une estimation plutôt réaliste de la complexité d’un mot de passe et permet de les rejeter en dessous d’un certain seuil.

Voir aussi

OpenID Connect identity provider¶

Ajouté dans la version 2026.11.

Weblate can act as an optional OpenID Connect (OIDC) identity provider for other applications. This is separate from signing in to Weblate using an external OIDC provider. The existing SAML identity provider can remain enabled.

Install the oidc extra (uv pip install Weblate[oidc]). Generate a signing key and keep it outside version control:

openssl genrsa -out /path/to/oidc.key 4096

Enable OIDC_PROVIDER_ENABLED, add the optional applications, and configure OAUTH2_PROVIDER in your settings:

from pathlib import Path

OIDC_PROVIDER_ENABLED = True
INSTALLED_APPS += ["weblate.oidc", "oauth2_provider"]
OAUTH2_PROVIDER = {
    "OIDC_RSA_PRIVATE_KEY": Path("/path/to/oidc.key").read_text(encoding="utf-8"),
}

Run migrate before starting Weblate and its workers. Disabled installations do not need these applications, dependencies, or database tables. For Docker, see WEBLATE_OIDC_PROVIDER_ENABLED.

Register each client in Django administration under Applications. Select Authorization code and RSA with SHA-256. For clients supporting a secret, select Confidential and securely copy the generated client ID and secret. Secrets are hashed when saved. For clients without a secret, select Public; S256 PKCE is required for both client types. Register the client’s exact HTTPS callback URL. Only select Skip authorization for trusted clients; other clients require user consent before accessing identity information.

The issuer is the canonical Weblate site URL followed by /oidc, including any URL_PREFIX. The discovery URL is the issuer followed by /.well-known/openid-configuration. Configure clients to use this discovery URL, authorization code flow, S256 PKCE, and scopes openid profile email. Confidential-client authentication supports HTTP Basic or a form-encoded client secret. For Zammad, register a public client, set its issuer to the Weblate issuer URL, select sub as the UID field, request openid profile email, and enable PKCE. Its callback is https://zammad.example.com/auth/openid_connect/callback. Nextcloud’s user_oidc app can use a confidential client with the discovery URL. Shared logout and automatic client registration are not provided.

Authorization requests can use GET or form-encoded POST. Clients exchange tokens and fetch UserInfo through their servers.

Clients can request fresh authentication using prompt=login or limit the age of the existing authentication using max_age in seconds. The limit also applies when submitting consent. max_age=0 always requires a new login. With prompt=none, Weblate returns login_required or consent_required when authentication or consent needs user interaction.

Federated sign-in can reuse an upstream session without revealing its authentication time. These sign-ins omit auth_time from ID tokens and cannot satisfy prompt=login or max_age requests; Weblate returns login_required instead. Use a password-based sign-in or e-mail verification when fresh authentication is required. A failed freshness request does not prevent later ordinary federated sign-ins.

The sub claim is the Weblate user ID as a string, stable across username and e-mail changes. The profile scope adds preferred_username, name, and family_name; both name claims contain Weblate’s full name. The email scope adds email and email_verified. Verification is reported only when the current address has a recorded verification. Claims are available in ID tokens and from /oidc/userinfo/ using an access token.

When Legal module is installed, clients can additionally request the optional weblate:legal scope. It adds weblate_tos_version to ID tokens and UserInfo, containing the version the user actually accepted as an ISO date, for example "2026-09-01". Older accepted versions are returned unchanged; the claim is omitted when no acceptance is recorded. Reading it does not record consent or expose the acceptance timestamp, IP address, or user agent. Without the legal module, this scope is unavailable.

Receiving servers using the same legal package, such as wllegal, can use this date to match their legal version. They must explicitly trust the issuer and match the accepted version to their own documents before suppressing local confirmation. This provider only exposes the information; accepting shared consent on receiving Weblate servers requires separate integration.

New browser sessions created for OIDC sign-in expire after 60 seconds, including when sign-in requires Authentification à deux facteurs. Existing browser sessions keep their expiry policy. Sessions created before the provider recorded an authentication time require a fresh sign-in before authorizing a client. If the browser session expires while the consent page is open, submitting the form restarts sign-in and displays a new consent page. The earlier approval or denial is discarded; the user must submit the new form. Concurrent authorization attempts are tracked separately. Pending attempts expire after 15 minutes; starting more than 16 discards the oldest attempt.

Access and ID tokens last one hour. Refresh tokens rotate on use and expire after 30 days of inactivity beyond their associated access token’s expiry. ID tokens retain the original authentication time across refreshes, including its absence for federated sign-ins, even when the user signs in again elsewhere. Reusing an already rotated refresh token revokes its token family. Tokens work independently of the browser session and do not authorize Weblate REST API access. Account removal deletes provider credentials, and inactive accounts cannot authorize or use provider tokens. Celery periodically cleans expired credentials.

To rotate signing keys, replace OIDC_RSA_PRIVATE_KEY and retain old private keys in OIDC_RSA_PRIVATE_KEYS_INACTIVE until outstanding ID tokens and cached key sets have expired. Only public key material is published by JWKS.

When migrating a client from SAML, explicitly map its existing identities to the OIDC issuer and subject. Do not assume SAML NameIDs equal OIDC subjects, or link accounts solely by matching e-mail addresses. For weblate.org, existing accounts are linked by persistent SAML provider/identity pairs; its client integration and identity mapping require a separate migration.

S’authentifier avec SAML¶

Ajouté dans la version 4.1.1.

Modifié dans la version 5.12: Les dépendances pour l’authentification SAML ne sont plus incluses par défaut dans les extras all. Vous devez inclure saml lors de l’installation de Weblate avec pip (uv pip install Weblate[all,saml]).

Merci de suivre les instructions d’authentification sociale de Python pour la configuration. Differences notables :

Weblate supporte single IDP qui doit être appelé weblate dans SOCIAL_AUTH_SAML_ENABLED_IDPS.
L’URL SAML des metadonnées XML est /accounts/metadata/saml/, qui est également l’ID d’une entité.
L’URL d’enregistrement est /accounts/complete/saml/ (connue également comme URL ACS).
Les paramètres suivants sont automatiquement remplis dans : SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

Exemple de configuration :

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.email.EmailAuth",
    "social_core.backends.saml.SAMLAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_SAML_SP_ENTITY_ID = f"https://{SITE_DOMAIN}/accounts/metadata/saml/"
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT = "-----BEGIN CERTIFICATE-----"
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY = "-----BEGIN PRIVATE KEY-----"
SOCIAL_AUTH_SAML_ENABLED_IDPS = {
    "weblate": {
        "entity_id": "https://idp.testshib.org/idp/shibboleth",
        "url": "https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO",
        "x509cert": "MIIEDjCCAvagAwIBAgIBADA ... 8Bbnl+ev0peYzxFyF5sQA==",
    }
}
SOCIAL_AUTH_SAML_ORG_INFO = {
    "en-US": {
        "name": "example",
        "displayname": "Example Inc.",
        "url": "http://example.com"
    }
}
SOCIAL_AUTH_SAML_TECHNICAL_CONTACT = {
    "givenName": "Tech Gal",
    "emailAddress": "technical@example.com"
}
SOCIAL_AUTH_SAML_SUPPORT_CONTACT = {
    "givenName": "Support Guy",
    "emailAddress": "support@example.com"
}

Vous pouvez générer une nouvelle paire de clés en utilisant :

openssl req -newkey rsa:4096 -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.key

La configuration par défaut extrait les détails de l’utilisateur depuis les attributs suivants, configurer votre IdP pour les remettre :

Attribut	Reference de l’URI SAML
Nom complet	`urn:oid:2.5.4.3`
Prénom	`urn:oid:2.5.4.42`
Nom de famille	`urn:oid:2.5.4.4`
Adresse courriel	`urn:oid:0.9.2342.19200300.100.1.3`
Nom d’utilisateur	`urn:oid:0.9.2342.19200300.100.1.1`

Lorsque vous configurez Weblate SP dans votre IdP, il est recommandé de choisir un format de Name ID persistant.

Indication

Some identity providers (such as Microsoft Entra ID with multi-factor authentication) require disabling the default requestedAuthnContext in the SAML security configuration:

SOCIAL_AUTH_SAML_SECURITY_CONFIG = {"requestedAuthnContext": False}

Dans Docker, définissez plutôt la variable d’environnement WEBLATE_SAML_SECURITY_CONFIG.

Indication

L’exemple ci-dessus et l’image Docker définissent un IdP appelé weblate. Vous devrez peut-être configurer cette chaîne en tant que Relay dans votre IdP (fournisseur d’identité).

Note

L’authentification Weblate utilise le paramètre RelayState passé au processus d’authentification. Ceci doit être configuré avec certains fournisseurs d’identité :

Comment envoyer un RelayState personnalisé avec Okta

Voir aussi

S’authentifier avec LDAP¶

C’est mieux de s’authentifier avec LDAP en utilisant le paquet django-auth-ldap. Vous pouvez l’installer comme d’habitude :

# Using PyPI
uv pip install 'django-auth-ldap>=1.3.0'

# Using apt-get
apt-get install python-django-auth-ldap

Indication

Ce package est inclus dans le conteneur Docker, voir Installation via Docker.

Note

Des incompatibilités dans le module Python LDAP 3.1.0 peuvent vous empêcher d’utiliser cette version. Si vous obtenez l’erreur AttributeError: “module” object has no attribute “_trace_level”, le retour à la version 3.0.0 de python-ldap pourrait résoudre le problème.

Une fois que le paquet est installé, vous pouvez le relier à l’authentification Django :

# Add LDAP backed, keep Django one if you want to be able to sign in
# even without LDAP for admin account
AUTHENTICATION_BACKENDS = (
    "django_auth_ldap.backend.LDAPBackend",
    "weblate.accounts.auth.WeblateUserBackend",
)

# LDAP server address
AUTH_LDAP_SERVER_URI = "ldaps://ldap.example.net"

# DN to use for authentication
AUTH_LDAP_USER_DN_TEMPLATE = "cn=%(user)s,o=Example"
# Depending on your LDAP server, you might use a different DN
# like:
# AUTH_LDAP_USER_DN_TEMPLATE = 'ou=users,dc=example,dc=com'

# List of attributes to import from LDAP upon sign in
# Weblate stores full name of the user in the full_name attribute
AUTH_LDAP_USER_ATTR_MAP = {
    "full_name": "name",
    # Use the following if your LDAP server does not have full name
    # Weblate will merge them later
    # 'first_name': 'givenName',
    # 'last_name': 'sn',
    # Email is required for Weblate (used in VCS commits)
    "email": "mail",
}
# Optional: route "Forgot your password?" to your LDAP self-service page
PASSWORD_RESET_URL = "https://id.example.net/password-reset/"


# Hide the registration form
REGISTRATION_OPEN = False

Note

Vous devez supprimer 'social_core.backends.email.EmailAuth' du paramètre AUTHENTICATION_BACKENDS, sinon les utilisateurs seront en mesure de définir leur mot de passe sur Weblate et de s’authentifier avec. Garder 'weblate.accounts.auth.WeblateUserBackend' est encore nécessaire pour gérer les permissions et autoriser l’utilisation anonyme. Cela permet aussi de s’identifier avec un compte administrateur local, si vous en avez créé un (p. ex. en utilisant createadmin).

En utilisant le mot de passe lié¶

Si vous ne pouvez pas utiliser la liaison directe pour l’authentification, vous devrez utiliser la recherche, et fournir un utilisateur à lier pour la recherche. Par exemple :

import ldap
from django_auth_ldap.config import LDAPSearch

AUTH_LDAP_BIND_DN = ""
AUTH_LDAP_BIND_PASSWORD = ""
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "ou=users,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(uid=%(user)s)"
)

Intégration avec Active Directory¶

import ldap
from django_auth_ldap.config import LDAPSearch, NestedActiveDirectoryGroupType

AUTH_LDAP_BIND_DN = "CN=ldap,CN=Users,DC=example,DC=com"
AUTH_LDAP_BIND_PASSWORD = "password"

# User and group search objects and types
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "CN=Users,DC=example,DC=com", ldap.SCOPE_SUBTREE, "(sAMAccountName=%(user)s)"
)

# Make selected group a superuser in Weblate
AUTH_LDAP_USER_FLAGS_BY_GROUP = {
    # is_superuser means user has all permissions
    "is_superuser": "CN=weblate_AdminUsers,OU=Groups,DC=example,DC=com",
}

# Map groups from AD to Weblate
AUTH_LDAP_GROUP_SEARCH = LDAPSearch(
    "OU=Groups,DC=example,DC=com", ldap.SCOPE_SUBTREE, "(objectClass=group)"
)
AUTH_LDAP_GROUP_TYPE = NestedActiveDirectoryGroupType()
AUTH_LDAP_FIND_GROUP_PERMS = True

# Optionally enable group mirroring from LDAP to Weblate
# AUTH_LDAP_MIRROR_GROUPS = True

Voir aussi

S’authentifier avec CAS¶

On peut s’authentifier avec CAS en utilisant un paquet tel que Django CAS NG.

La première étape est de révéler le champ e-mail de l’utilisateur via CAS. Cela doit être configuré sur le serveur de CAS, et demande d’utiliser au moins CAS v2 vu que CAS v1 ne supporte pas du tout les attributs.

L’étape suivante est de mettre à jour Weblate pour utiliser votre server CAS et les attributs.

Pour installer Django CAS NG :

uv pip install django-cas-ng

Une fois que le paquet est installé vous pouvez relier au système d’authentification Django en modifiant le fichier settings.py :

# Add CAS backed, keep the Django one if you want to be able to sign in
# even without LDAP for the admin account
AUTHENTICATION_BACKENDS = (
    "django_cas_ng.backends.CASBackend",
    "weblate.accounts.auth.WeblateUserBackend",
)

# CAS server address
CAS_SERVER_URL = "https://cas.example.net/cas/"

# Add django_cas_ng somewhere in the list of INSTALLED_APPS
INSTALLED_APPS = (..., "django_cas_ng")

Au final, un signal peut être utiliser pour assigner le champ e-mail à l’objet utilisateur. Pour que cela fonctionne, vous devez importer le signal depuis le paquet django-cas-ng et connecter votre code à ce signal. Faire cette manipulation depuis les fichiers de configuration peut être problématique, alors on conseille de faire différemment :

Dans la méthode django.apps.AppConfig.ready() de la configuration de l’application
Dans le fichier urls.py du projet (quand il n’existe pas de modèle)

from django_cas_ng.signals import cas_user_authenticated
from django.dispatch import receiver


@receiver(cas_user_authenticated)
def update_user_email_address(sender, user=None, attributes=None, **kwargs):
    # If your CAS server does not always include the email attribute
    # you can wrap the next two lines of code in a try/catch block.
    user.email = attributes["email"]
    user.save()

Configurer l’authentification Django avec des services tiers¶

Généralement n’importe quel module d’authentification Djano devrait fonctionner avec Weblate. Il suffit de suivre les instructions du module et de se rappeler de conserver le backend utilisateur de Weblate.

Voir aussi

S’authentifier avec LDAP
S’authentifier avec CAS

Typiquement l’installation va consister à l’ajout d’un backend d’authentification à AUTHENTICATION_BACKENDS et l’installation d’une app d’authentification (s’il y en une) dans INSTALLED_APPS :

AUTHENTICATION_BACKENDS = (
    # Add authentication backend here
    "weblate.accounts.auth.WeblateUserBackend",
)

INSTALLED_APPS += (
    # Install authentication app here
)

Authentification à deux facteurs¶

Ajouté dans la version 5.7.

Indication

L’authentification à deux facteurs ajoute un niveau supplémentaire de sécurité à votre compte en demandant plus qu’un simple mot de passe pour se connecter.

Weblate reconnait les seconds facteurs suivants :

Clés de sécurité (WebAuthn)

A la fois la clé secrète et la clé de sécurité sont prises en charge.

Les clés de passe valident votre identité en utilisant l’empreinte digitale, la reconnaissance faciale, un mot de passe de l’appareil, ou un code PIN puisqu’elles incluent la vérification de l’utilisateur.

Les clés de sécurité sont des informations confidentielles WebAuthn qui ne peuvent être utilisées qu’en tant que second facteur d’authentification et elles ne servent qu’à valider la présence de l’utilisateur.

When signing in on a new computer or in a different browser, your passkey might not be available. Use a device where the passkey is available, or connect your registered security key. A verification error can mean that the request timed out, was canceled, or that the credential is unavailable; it does not identify the exact cause.

You can also select another configured verification method on the sign-in page, such as Use recovery codes. If you cannot use any configured method, contact the site administrator for help.

Applications d’authentification (TOTP)

Les applications d’authentification et les extensions de navigateurs telles que Aegis, Bitwarden, Google Authenticator, 1Password, Authy, Microsoft Authenticator, etc. génèrent des mots de passe uniques basés sur l’heure et utilisés en tant que second facteur pour vérifier votre identité lorsqu’elle vous est demandée à la connexion.

Registration becomes active only after you verify a code from the app. Complete registration within 24 hours; otherwise start again with a new QR code. Each registration can be completed only once. After registering, wait for the next code before using the app to sign in.

Only one registration can be pending per account. Opening registration in another browser session shows the same QR code until registration is completed or expires.

If you have more than one registered authenticator app, select the app you are using when entering its code during sign-in.

Codes de récupération

Les codes de récupération peuvent être utilisés pour accéder à votre compte si vous perdez l’accès à votre équipement et que vous ne pouvez plus recevoir les codes d’identification à deux facteurs.

Gardez vos codes de récupération dans un endroit sûr tout comme vos mots de passe. Nous recommandons de les enregistrer avec un gestionnaire de mots de passe tel que Bitwarden, 1Password, Authy, ou Keeper.

Each user can configure this in Security and second factor will be required to sign in addition to the existing authentication method.

Cette mesure peut être appliquée aux utilisateurs au niveau du projet (voir Authentification à deux facteurs obligatoire) ou de l’équipe. Dans le cadre de déploiements à l’échelle du site, elle peut également servir à imposer l’authentification à deux facteurs à tous les utilisateurs en l’activant sur l’équipe par défaut Users, qui est automatiquement attribuée aux nouveaux utilisateurs par automatic team assignment.

Les privilèges d’un groupe utilisant l’authentification à deux facteurs ne seront pas appliqués aux utilisateurs qui ne l’auront pas configurée.

Authentification¶

Enregistrement utilisateur¶

Serveurs d’authentification¶

Teams from identity providers¶