Django AUTHENTICATION_BACKENDS :
la liste qui pilote les connexions
AUTHENTICATION_BACKENDS est le paramètre Django qui liste les backends d'authentification à utiliser ; Django les essaie dans l'ordre jusqu'à ce que l'un valide l'utilisateur.
Vous avez écrit un backend d’authentification personnalisé — AUTHENTICATION_BACKENDS dit à Django de l’utiliser. Ce paramètre liste les backends à essayer lors de chaque connexion. Django les parcourt dans l’ordre : le premier qui renvoie un utilisateur valide gagne ; les autres renvoient None et passent la main.
L’ordre décide de qui se connecte.
Combinaison de backends
En PME, les salariés se connectent souvent via LDAP, tandis que les comptes de service restent locaux : placez le backend LDAP en premier, puis ModelBackend. Autoriser la connexion par adresse e-mail ? Écrivez un backend personnalisé avant ModelBackend, et les deux modes cohabitent.
Attention : dès que vous déclarez AUTHENTICATION_BACKENDS, Django n’applique plus ModelBackend par défaut. Réincluez-le si vous voulez conserver la connexion standard.
Consulte écrire un authentication backend pour coder votre classe, et Django comme back-end pour le contexte serveur. Projet Django à sécuriser ? Appelez au 0476 07 23 28 — premier échange gratuit.
Notions liées.
Le réseau de notions autour de cette fiche — chaque entrée renvoie vers sa propre définition.
Django auth backend expliqué
Le principe général du système enfichable.
Écrire un authentication backend
Créer la classe qu'on déclarera dans ce réglage.
Django comme back-end
Le rôle serveur global du framework.
Développement back-end en Python
Le contexte serveur plus large.
Le back-end, côté serveur
Les fondamentaux du développement serveur.
Ce qu'on nous demande souvent.
Une question qui n'est pas ici ? Écrivez-nous : on répond en clair, sans jargon, sous 24 h.
Poser votre questionÀ quoi sert le paramètre AUTHENTICATION_BACKENDS ?
C'est la liste, définie dans les réglages du projet, des backends d'authentification que Django doit utiliser. Chaque entrée pointe vers une classe.
Lorsqu'un utilisateur tente de se connecter, Django parcourt cette liste et confie la vérification à chaque backend, dans l'ordre, jusqu'à ce que l'un renvoie un utilisateur valide.
Quelle est la valeur par défaut ?
Si vous ne précisez rien, Django utilise le ModelBackend, qui vérifie les identifiants contre la base de données.
Dès que vous déclarez AUTHENTICATION_BACKENDS vous-même, cette valeur par défaut n'est plus appliquée automatiquement : pensez à réinclure le ModelBackend dans la liste si vous voulez conserver la connexion classique en plus de vos backends personnalisés.
L'ordre des backends a-t-il de l'importance ?
Oui, l'ordre est déterminant. Django essaie les backends de haut en bas et s'arrête au premier qui authentifie l'utilisateur.
Placer un annuaire externe avant les comptes locaux, ou l'inverse, change donc le comportement. C'est aussi vrai pour les permissions : Django consulte les backends dans le même ordre.
Peut-on combiner plusieurs backends ?
C'est précisément l'intérêt du paramètre. On peut, par exemple, tenter d'abord une authentification via un fournisseur externe, puis retomber sur le ModelBackend pour les comptes gérés localement.
Chaque backend reste responsable de son propre périmètre, et la liste orchestre l'ensemble.
Que se passe-t-il si aucun backend n'authentifie ?
Si tous les backends de la liste renvoient None, l'authentification échoue et l'utilisateur n'est pas connecté.
C'est le comportement attendu : chaque backend a eu sa chance de valider l'identité, aucun n'a réussi, la connexion est donc refusée.