Authentification avec Django et les applications à page unique (2020)

Publié il y a plus de 2 ans.

Lorsque vous utilisez Django pour une application d'une seule page comme une application React, Vue ou Angular, une première question initiale typique est : "comment puis-je gérer l'authentification ?"

Il existe quelques options pour les utilisateurs :

Utiliser les jetons Web JSON Utiliser l'authentification par jeton de REST Framework Utilisez django-rest-knox (une amélioration par rapport à TokenAuthentication de REST Framework)

C'est certainement une cause de confusion parmi les développeurs (moi y compris).

J'aimerais proposer une troisième option : utilisez simplement Django. Si vous êtes simplement curieux de savoir comment procéder, consultez l'exemple d'application Django et React.

Regardons d'abord les options mentionnées ci-dessus et expliquons leurs lacunes.

Les JWT sont une nouvelle norme (2010) pour représenter les réclamations entre deux parties.

La "réclamation" peut être n'importe quoi, mais elle est généralement aussi simple que : "Je suis l'utilisateur 1234, veuillez me laisser accéder à la ressource sur /api/quelquechose".

Le serveur peut rapidement valider l'exactitude de la demande à l'aide de la signature hachée contenue dans un JWT (pour plus d'informations, lisez l'introduction de JWT).

Ainsi, à chaque requête, nous envoyons le JWT via un en-tête HTTP :

OK cool, nous ne comprenons peut-être pas tout en ce qui concerne les JWT, mais nous obtenons qu'un serveur nous donne un jeton, nous l'incluons dans chaque requête, et nous avons accès à notre ressource protégée /api/something.

Mais si nous devons envoyer ceci à chaque requête, nous devons conserver ces informations d'identification quelque part. Dans un environnement mobile natif, il existe des options sécurisées, mais sur les navigateurs, nous n'avons que localStorage ou sessionStorage, qui sont tous deux 100 % non sécurisés.

localStorage et sessionStorage sont vulnérables aux attaques de script intersite (XSS).

Les navigateurs n'ont vraiment qu'un seul endroit à l'abri de ces attaques : les cookies (notez que les cookies non HTTP stockés et accessibles via document.cookie ne sont pas sécurisés car d'autres scripts sont capables de les lire). Nous pourrions stocker des JWT dans des cookies, mais il y a encore des problèmes plus fondamentaux avec les JWT.

Premièrement et surtout, les JWT sont vulnérables aux attaques par force brute une fois interceptés. Ainsi, ils sont fortement recommandés comme mécanisme d'authentification temporaire pour obtenir quelque chose de plus sécurisé comme un identifiant de session ou un jeton d'accès OAuth (stocké via un cookie).

L'autre problème avec les JWT est qu'ils ne peuvent pas être invalidés, ce qui est un problème si vous souhaitez gérer l'un de ces cas :

Se déconnecter comptes compromis changements de mot de passe modifications d'autorisation déprovisionnement de l'utilisateur

En bref, si vous utilisez des JWT, veuillez vous assurer qu'ils sont de courte durée et échangés contre quelque chose de plus sécurisé.

Django REST Framework offre un mécanisme TokenAuthentication intégré qui crée des jetons secrets pour chaque utilisateur et les émet via une vue intégrée (rest_framework.authtoken.views.obtain_auth_token).

Une fois l'authentification réussie, cette vue renvoie une réponse JSON avec un jeton que nous pouvons envoyer via un en-tête HTTP :

Cette méthode est correcte, mais encore une fois dans un contexte de navigateur, nous sommes confrontés au même dilemme : où stockons-nous ce jeton ?

Si seulement Django nous donnait un jeton sécurisé stocké via des cookies que nous pourrions utiliser à chaque demande... oh attendez, c'est le cas !

Django contient une méthode login() qui émet commodément un cookie sessionid dans la réponse HTTP.

Le cadre REST fournit un