---
title: "Comment authentifier avec REMOTE_USER"
version: 6.0
locale: fr
source: https://docs.djangoproject.com/fr/6.0/howto/auth-remote-user/
canonical: https://djangodocs.dev/fr/6.0/howto/auth-remote-user/
---
# Comment authentifier avec `REMOTE_USER`

This document describes how to make use of external authentication sources in
your Django applications. This type of authentication solution is typically
seen on intranet sites, with single sign-on solutions such as IIS and
Integrated Windows Authentication or Apache and [mod\_authnz\_ldap](https://httpd.apache.org/docs/current/mod/mod_authnz_ldap.html), [CAS](https://www.apereo.org/projects/cas),
[WebAuth](https://uit.stanford.edu/service/authentication), [mod\_auth\_sspi](https://sourceforge.net/projects/mod-auth-sspi), etc.

When the web server takes care of authentication it typically provides the
authenticated user as `REMOTE_USER`. In Django, this value is made available
in [`request.META`](/fr/6.0/ref/request-response/#django.http.HttpRequest.META) (as `REMOTE_USER` when
supplied as an environment variable, as in WSGI, or `HTTP_REMOTE_USER` when
supplied via an HTTP header, as in ASGI). Django can be configured to make use
of the `REMOTE_USER` value using the `RemoteUserMiddleware` or
`PersistentRemoteUserMiddleware`, and
[`RemoteUserBackend`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) classes found in
[`django.contrib.auth`](/fr/6.0/topics/auth/#module-django.contrib.auth).

## Configuration

Vous devez tout d’abord ajouter [`django.contrib.auth.middleware.RemoteUserMiddleware`](/fr/6.0/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) au réglage [`MIDDLEWARE`](/fr/6.0/ref/settings/#std-setting-MIDDLEWARE) **après** la valeur [`django.contrib.auth.middleware.AuthenticationMiddleware`](/fr/6.0/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) :

```
MIDDLEWARE = [
    "...",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.auth.middleware.RemoteUserMiddleware",
    "...",
]
```

Puis, vous devez remplacez [`ModelBackend`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend) par [`RemoteUserBackend`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) dans le réglage [`AUTHENTICATION_BACKENDS`](/fr/6.0/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) :

```
AUTHENTICATION_BACKENDS = [
    "django.contrib.auth.backends.RemoteUserBackend",
]
```

With this setup, `RemoteUserMiddleware` will detect the username in
`request.META['REMOTE_USER']` (or `request.META['HTTP_REMOTE_USER']` under
ASGI) and will authenticate and auto-login that user
using the [`RemoteUserBackend`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend).

Soyez conscient que cette configuration particulière désactive l’authentification avec le `ModelBackend` par défaut. Cela signifie que si la valeur de `REMOTE_USER` n’est pas configurée, l’utilisateur ne parviendra pas à se connecter, même en utilisant l’interface d’administration de Django. Ajouter `'django.contrib.auth.backends.ModelBackend'` à la liste des `AUTHENTICATION_BACKENDS` utilisera `ModelBackend` comme solution de repli si `REMOTE_USER` est absent, ce qui permettra de résoudre ces problèmes.

La gestion des utilisateurs de Django, tels que les vue de `contrib.admin` et la commande de gestion [`createsuperuser`](/fr/6.0/ref/django-admin/#django-admin-createsuperuser), ne s’intègrent pas avec des utilisateurs distants. Ces interfaces travaillent avec les utilisateurs stockés dans la base de données indépendamment de \`\` AUTHENTICATION\_BACKENDS\`\`.

> **Note**
>
> Comme `RemoteUserBackend` hérite de `ModelBackend`, le contrôle des permissions implémenté dans `ModelBackend` est toujours disponible.
>
> Les utilisateurs avec [`is_active=False`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.models.User.is_active) ne seront pas autorisés à s’authentifier. Utilisez [`AllowAllUsersRemoteUserBackend`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.backends.AllowAllUsersRemoteUserBackend) si vous voulez les autoriser à se connecter.

Si votre mécanisme d’authentification utilise un en-tête HTTP personnalisé à la place de `REMOTE_USER`, vous pouvez créer une sous-classe de `RemoteUserMiddleware` et définir l’attribut `header` à la clé de `request.META` désirée. Par exemple :

*`monsite/middleware.py`*

```python
 from django.contrib.auth.middleware import RemoteUserMiddleware

 class CustomHeaderRemoteUserMiddleware(RemoteUserMiddleware):
     header = "HTTP_AUTHUSER"
```

Cet intergiciel personnalisé est alors utilisé dans le réglage [`MIDDLEWARE`](/fr/6.0/ref/settings/#std-setting-MIDDLEWARE) à la place de [`django.contrib.auth.middleware.RemoteUserMiddleware`](/fr/6.0/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware):

```
MIDDLEWARE = [
    "...",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "mysite.middleware.CustomHeaderRemoteUserMiddleware",
    "...",
]
```

> **Warning**
>
> `RemoteUserMiddleware` must not be deployed in configurations where a
> client can supply the header. You must be sure that your web server or
> reverse proxy always sets or strips that header based on the appropriate
> authentication checks, never permitting an end user to submit a fake (or
> « spoofed ») header value.
>
> Comme les en-têtes HTTP `X-Auth-User` et `X-Auth_User` (par exemple) sont tous deux normalisés en `HTTP_X_AUTH_USER` dans `request.META`, vous devez aussi contrôler que votre serveur web n’autorise pas d’en-tête fabriqué qui utiliserait des soulignements à la place des tirets.
>
> Under WSGI, this warning doesn’t apply to `RemoteUserMiddleware` in its
> default configuration with `header = "REMOTE_USER"`, since a key that
> doesn’t start with `HTTP_` in `request.META` can only be set by your
> WSGI server, not directly from an HTTP request header.
>
> This warning applies under ASGI in all configurations, because there is
> no equivalent for a WSGI server’s ability to place a trusted value in the
> environ. ASGI deployments *must* use a reverse proxy as described above
> when using this middleware.

Si vous avez besoin de plus de maîtrise, vous pouvez créer votre propre moteur d’authentification héritant de [`RemoteUserBackend`](/fr/6.0/ref/contrib/auth/#django.contrib.auth.backends.RemoteUserBackend) et surcharger un ou plusieurs de ses attributs et méthodes.

## Utilisation de `REMOTE_USER` uniquement pour les pages de connexion

L’intergiciel d’authentification `RemoteUserMiddleware` part du principe que l’en-tête de requête HTTP `REMOTE_USER` est présent pour toutes les requêtes authentifiées. C’est en général le cas lorsqu’un mécanisme du genre Basic HTTP Auth avec `htpasswd` est utilisé, mais avec des méthodes d’authentification comme Negotiate (GSSAPI/Kerberos) ou autres méthodes gourmandes en ressources, l’authentification au niveau du serveur HTTP frontal n’est habituellement configurée que pour une ou quelques URL de connexion ; après une authentification réussie, l’application est censé maintenir elle-même la session authentifiée.

[`PersistentRemoteUserMiddleware`](/fr/6.0/ref/middleware/#django.contrib.auth.middleware.PersistentRemoteUserMiddleware) prend en charge ce cas d’utilisation. Il maintient la session authentifiée jusqu’à une déconnexion explicite par l’utilisateur. Cette classe peut être utilisée en remplacement de [`RemoteUserMiddleware`](/fr/6.0/ref/middleware/#django.contrib.auth.middleware.RemoteUserMiddleware) dans la documentation ci-dessus sans autre modification.