Question

Que signifie "authentification RESTful" et comment fonctionne-t-il? Je ne trouve pas un bon aperçu sur Google. Ma seule compréhension est que vous passez la clé de session (remeberal) dans l’URL, mais cela pourrait être horriblement faux.

Était-ce utile?

La solution

La gestion de l’authentification dans une architecture RESTful Client-Server fait l’objet d’un débat.

Généralement, cela peut être réalisé dans le monde SOA via HTTP via:

  • Authentification de base HTTP sur HTTPS;
  • Gestion des cookies et des sessions;
  • Jeton dans les en-têtes HTTP (par exemple, OAuth 2.0 + JWT);
  • Authentification de requête avec des paramètres de signature supplémentaires.

Vous devrez adapter, ou même mieux combiner ces techniques, pour correspondre au mieux à votre architecture logicielle.

Chaque schéma d'authentification a ses propres PRO et CON, en fonction de l'objectif de votre politique de sécurité et de votre architecture logicielle.

Authentification HTTP de base sur HTTPS

Cette première solution, basée sur le protocole HTTPS standard, est utilisée par la plupart des services Web. 

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Facile à mettre en œuvre, disponible par défaut sur tous les navigateurs, mais présente certains inconvénients connus, tels que la terrible fenêtre d'authentification affichée sur le navigateur, qui persistera (il n'y a pas de fonctionnalité semblable à LogOut ici), d'autres supplémentaires côté serveur. Consommation de l'unité centrale et le fait que le nom d'utilisateur et le mot de passe sont transmis (via HTTPS) au serveur (il devrait être plus sûr de laisser le mot de passe rester uniquement du côté client, lors de la saisie au clavier, et être stocké en tant que hachage sécurisé le serveur).

Nous pouvons utiliser Authentification Digest , mais elle requiert également HTTPS, car elle est vulnérable à < un href = "http://en.wikipedia.org/wiki/Man-in-the-middle_attack" rel = "noreferrer"> MiM ou Replay , spécifique à HTTP.

Session via les cookies

Pour être honnête, une session gérée sur le serveur n'est pas vraiment sans état.

Une possibilité pourrait être de conserver toutes les données dans le contenu du cookie. Et, à dessein, le cookie est géré côté serveur (le client, en fait, n'essaye même pas d'interpréter ces données de cookie: il les remet simplement au serveur à chaque requête successive). Mais ces données de cookie sont des données d'état d'application, le client doit donc les gérer, pas le serveur, dans un monde pur sans état. 

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

La technique de cookie elle-même est liée à HTTP, elle n'est donc pas vraiment RESTful, elle devrait être indépendante du protocole, à mon humble avis. Il est vulnérable aux MiM ou Replay attaques.

Accordé via un jeton (OAuth2)

Une autre solution consiste à insérer un jeton dans les en-têtes HTTP afin que la demande soit authentifiée. C’est ce que fait OAuth 2.0, par exemple. Voir la RFC 6749 : 

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

En résumé, cela ressemble beaucoup à un cookie et présente les mêmes problèmes: non apatride, reposant sur les détails de la transmission HTTP et soumise à de nombreuses faiblesses en matière de sécurité , y compris MiM et Replay, ne doivent être utilisées que sur HTTPS. En règle générale, un JWT est utilisé comme jeton.

Authentification de la requête

L’authentification de requête consiste à signer chaque requête RESTful via des paramètres supplémentaires sur l’URI. Voir cet article de référence .

Il a été défini comme tel dans cet article:

  

Toutes les requêtes REST doivent être authentifiées en signant les paramètres de requête.   triés par ordre alphabétique en minuscules à l'aide des informations d'identification privées   comme le jeton de signature. La signature doit avoir lieu avant que l’URL ne code.   chaîne de requête.

Cette technique est peut-être la plus compatible avec un Stateles

Autres conseils

Je doute que les gens crient avec enthousiasme "Authentification HTTP". jamais essayé de créer une application basée sur un navigateur (au lieu d’un service Web de machine à machine) avec REST (aucune infraction envisagée - je ne pense pas qu’ils aient été confrontés à des complications).

Les problèmes rencontrés lors de l'utilisation de l'authentification HTTP sur des services RESTful générant des pages HTML à afficher dans un navigateur sont les suivants:

  • utilisateur obtient généralement une boîte de connexion laide faite par le navigateur, qui est très hostile à l'utilisateur. vous ne pouvez pas ajouter de récupération de mot de passe, de boîtes d’aide, etc.
  • la déconnexion ou la connexion sous un nom différent pose un problème - les navigateurs continueront à envoyer des informations d'authentification au site jusqu'à la fermeture de la fenêtre
  • les délais d'attente sont difficiles

Un ici est un article très perspicace qui aborde ces problèmes point par point. dans un lot d'hackery javascript spécifique au navigateur, de solutions de contournement, et cetera. En tant que tel, il n’est pas compatible avec les versions antérieures et nécessitera donc une maintenance constante au fur et à mesure de la sortie des nouveaux navigateurs. Je ne considère pas ce design épuré et clair, mais j’ai le sentiment que c’est beaucoup de travail supplémentaire et de maux de tête, juste pour pouvoir montrer mon badge REST avec enthousiasme à mes amis.

Je crois que les cookies sont la solution. Mais attendez, les cookies sont diaboliques, n'est-ce pas? Non, ils ne le sont pas, la façon dont les cookies sont souvent utilisés est diabolique. Un cookie en soi n'est qu'un élément d'information côté client, tout comme les informations d'authentification HTTP que le navigateur garderait pendant que vous naviguez. Et cette information côté client est envoyée au serveur à chaque demande, tout comme l’information d’authentification HTTP. Conceptuellement, la seule différence est que le contenu de cet élément d’état côté client peut être déterminé par le serveur dans le cadre de sa réponse.

En faisant des sessions une ressource RESTful avec uniquement les règles suivantes:

  • Une session associe une clé à un identifiant d'utilisateur (et éventuellement à un horodatage de dernière action pour les délais d'expiration)
  • Si une session existe, cela signifie que la clé est valide.
  • Login signifie un POST sur / sessions, une nouvelle clé est définie comme cookie
  • Déconnexion signifie SUPPRIMER / sessions / {clé} (avec le POST surchargé, rappelez-vous, nous sommes un navigateur, et HTML 5 est encore un long chemin à parcourir)
  • L’authentification est effectuée en envoyant la clé sous forme de cookie à chaque demande et en vérifiant si la session existe et est valide

La seule différence par rapport à l'authentification HTTP, à présent, réside dans le fait que la clé d'authentification est générée par le serveur et envoyée au client qui la renvoie, au lieu que le client la calcule à partir des informations d'identification entrées.

converter42 ajoute que, lorsque nous utilisons https (ce que nous devrions faire), il est important que le cookie ait son indicateur sécurisé défini afin que les informations d'authentification ne soient jamais envoyées via une connexion non sécurisée. Excellent point, je ne l’avais pas vu moi-même.

Je pense qu'il s'agit d'une solution suffisante qui fonctionne bien, mais je dois admettre que je ne suis pas assez expert en sécurité pour identifier les failles potentielles de ce schéma. Tout ce que je sais, c'est que des centaines d'applications Web non RESTful utilisent essentiellement le même protocole de connexion ($ _SESSION en PHP, HttpSession en Java EE, etc.). Le contenu de l'en-tête de cookie est simplement utilisé pour adresser une ressource côté serveur, tout comme une langue acceptée peut être utilisée pour accéder aux ressources de traduction, etc. Je pense que c'est pareil, mais peut-être que d'autres non? Qu'en pensez-vous, les gars?

Les gens bien en disent déjà assez sur ce sujet. Mais voici mes 2 cents.

Il existe 2 modes d'interaction:

  1. homme à machine (HTM)
  2. machine à machine (MTM)

La machine est le dénominateur commun, exprimé en tant qu'API REST, et les acteurs / clients étant les êtres humains ou les machines.

Désormais, dans une architecture véritablement RESTful, le concept d'état sans état implique que tous les états d'application pertinents (c'est-à-dire les états côté client) doivent être fournis avec chaque requête. Par pertinent, on entend que tout ce qui est requis par l'API REST pour traiter la demande et fournir une réponse appropriée.

Lorsque nous considérons cela dans le contexte d'applications homme-machine, "basé sur un navigateur" Comme Skrebbel le souligne ci-dessus, cela signifie que l'application (Web) exécutée dans le navigateur doit envoyer son état et les informations pertinentes avec chaque demande adressée aux API REST principales.

Considérez ceci: vous avez une ressource exposée d'API REST exposée sur la plateforme de données / d'information. Peut-être avez-vous une plateforme de BI en libre-service qui gère tous les cubes de données. Mais vous voulez que vos clients (humains) y aient accès via (1) une application Web, (2) une application mobile et (3) une application tierce. En fin de compte, même la chaîne de MTM mène à HTM - à droite. Les utilisateurs humains restent donc au sommet de la chaîne d'information.

Dans les 2 premiers cas, vous avez affaire à une interaction homme-machine, les informations étant effectivement consommées par un utilisateur humain. Dans le dernier cas, vous avez un programme d'ordinateur qui utilise les API REST.

Le concept d'authentification s'applique à tous les niveaux. Comment allez-vous concevoir cela pour que vos API REST soient accessibles de manière uniforme et sécurisée? À mon avis, il y a deux façons:

Voie 1:

  1. Il n'y a pas de login pour commencer. Chaque demande effectue la connexion
  2. Le client envoie ses paramètres d'identification + la requête spécifique paramètres à chaque requête
  3. L'API REST les prend, se retourne, envoie un ping au magasin de l'utilisateur (quel que soit ce qui est) et confirme l’authentification
  4. Si l'authentification est établie, répond à la demande; sinon, nie avec le code de statut HTTP approprié
  5. Répétez la procédure ci-dessus pour chaque requête de toutes les API REST de votre catalogue

Voie 2:

  1. Le client commence par une demande d'authentification
  2. Une API REST de connexion traitera toutes ces demandes
  3. Il prend en compte les paramètres d'authentification (clé API, uid / pwd ou quoi que vous fassiez). choisissez) et vérifie l’authentification par rapport au magasin de l’utilisateur (bases de données LDAP, AD ou MySQL, etc.)
  4. S'il est vérifié, crée un jeton d'authentification et le rend au client / appelant
  5. L'appelant envoie ensuite ce jeton d'autorisation + les paramètres spécifiques à la demande avec toute requête ultérieure adressée à d'autres API REST d'entreprise jusqu'à la déconnexion ou à l'expiration du bail

De toute évidence, dans la voie 2, les API REST auront besoin d’un moyen de reconnaître et de faire confiance au jeton comme étant valide. L'API de connexion a effectué la vérification de l'authentification, et par conséquent, cette "clé de service". doit être approuvé par les autres API REST de votre catalogue.

Cela signifie bien entendu que la clé / le jeton d'authentification devra être stocké et partagé entre les API REST. Ce référentiel de jetons partagé et approuvé peut être local / fédéré, ce qui permet aux API REST d'autres organisations de se faire mutuellement confiance.

Mais je m'égare.

Il s’agit d’un "état". (concernant le statut authentifié du client) doit être géré et partagé afin que toutes les API REST puissent créer un cercle de confiance. Si nous ne le faisons pas, ce qui correspond à la Voie 1, nous devons accepter qu’un acte d’authentification doit être effectué pour toutes les demandes qui arrivent.

L’authentification est un processus gourmand en ressources. Imaginez que vous exécutiez des requêtes SQL, pour chaque demande entrante, dans votre magasin d'utilisateurs pour vérifier la correspondance uid / pwd. Ou, pour chiffrer et effectuer un hachage

Voici une solution d’authentification véritablement et complètement RESTful:

  1. Créez une paire de clés publique / privée sur le serveur d'authentification.
  2. Distribuez la clé publique à tous les serveurs.

  3. Lorsqu'un client s'authentifie:

    3.1. émettre un jeton contenant les éléments suivants:

    • heure d'expiration
    • nom d'utilisateur (facultatif)
    • IP des utilisateurs (facultatif)
    • hash d'un mot de passe (facultatif)

    3.2. Cryptez le jeton avec la clé privée.

    3.3. Renvoyez le jeton chiffré à l'utilisateur.

  4. Lorsque l'utilisateur accède à une API, il doit également transmettre son jeton d'authentification.

  5. Les serveurs peuvent vérifier la validité du jeton en le déchiffrant à l'aide de la clé publique du serveur d'authentification.

Il s'agit d'une authentification sans état / RESTful.

Notez que si un hachage de mot de passe était inclus, l'utilisateur enverrait également le mot de passe non chiffré avec le jeton d'authentification. Le serveur peut vérifier que le mot de passe correspond au mot de passe utilisé pour créer le jeton d'authentification en comparant les hachages. Une connexion sécurisée utilisant quelque chose comme HTTPS serait nécessaire. Du côté client, Javascript peut gérer l’obtention du mot de passe de l’utilisateur et son stockage, soit en mémoire, soit dans un cookie, éventuellement chiffré avec la clé publique du serveur.

Pour être honnête avec vous, j’ai trouvé d’excellentes réponses ici, mais ce qui m’inquiète un peu, c’est lorsque l’on prend tout le concept d’Étateless à l’extrême où il devient dogmatique. Cela me rappelle ces vieux fans de Smalltalk qui voulaient seulement embrasser le pur OO et si quelque chose n'est pas un objet, alors vous le faites mal. Donnez-moi une pause.

L’approche RESTful est supposée vous faciliter la vie et réduire les frais généraux et les coûts des sessions, essayez de la suivre car c’est une bonne chose à faire, mais dès que vous suivez une discipline (toute discipline / directive) jusqu’au extrême où il ne procure plus les avantages pour lesquels il était destiné, vous le faites mal. Certains des meilleurs langages actuels ont à la fois une programmation fonctionnelle et une orientation objet.

Si le moyen le plus simple de résoudre votre problème est de stocker la clé d'authentification dans un cookie et de l'envoyer sur un en-tête HTTP, faites-le, n'en abusez pas. N'oubliez pas que les sessions sont mauvaises lorsqu'elles deviennent lourdes et volumineuses. Si votre session est constituée d'une courte chaîne contenant une clé, quel est le problème?

Je suis ouvert à accepter les corrections dans les commentaires, mais je ne vois tout simplement pas l'intérêt (jusqu'à présent) de rendre nos vies misérables, tout simplement en évitant de garder un grand dictionnaire de hachages sur notre serveur.

Tout d’abord, un service Web RESTful est STATELESS (ou SESSIONLESS ). Par conséquent, un service RESTful n’a pas et ne devrait pas avoir de concept de session ou de cookies impliqué. L'authentification ou l'autorisation dans le service RESTful consiste à utiliser l'en-tête HTTP Authorization tel que défini dans les spécifications HTTP RFC 2616. Chaque requête doit contenir l'en-tête HTTP Authorization et être transmise via une connexion HTTP (SSL). C’est la manière correcte de procéder à l’authentification et de vérifier l’autorisation des demandes dans un service Web HTTP RESTful. J'ai mis en place un service Web RESTful pour l'application Cisco PRIME Performance Manager chez Cisco Systems. Et dans le cadre de ce service Web, j'ai également implémenté l'authentification / autorisation.

Rubens Gomes.

Il ne s'agit certainement pas de " clés de session " comme il est généralement utilisé pour faire référence à l'authentification sans session qui est effectuée dans toutes les contraintes de REST. Chaque demande est auto-descriptive et contient suffisamment d’informations pour l’autoriser par elle-même, sans état d’application côté serveur.

La meilleure façon de procéder consiste à utiliser les mécanismes d'authentification intégrés à HTTP dans la RFC 2617 <. / a>.

L'article "très perspicace" mentionné par @skrebel ( http://www.berenddeboer.net /rest/authentication.html ) discute d'une méthode d'authentification compliquée mais vraiment inefficace.

Vous pouvez essayer de visiter la page (censée être visible par un utilisateur authentifié uniquement) http://www.berenddeboer.net/rest/site/authenticated.html sans identifiant de connexion.

(Désolé, je ne peux pas commenter la réponse.)

Je dirais que REST et l’authentification ne font tout simplement pas bon ménage. REST signifie sans état mais «authentifié» est un état. Vous ne pouvez pas avoir les deux à la même couche. Si vous êtes un avocat RESTful et que vous blâmez les États, vous devez utiliser le protocole HTTPS (c’est-à-dire laisser la question de la sécurité à un autre niveau).

Je pense que l'authentification reposante implique le passage d'un jeton d'authentification en tant que paramètre de la demande. Des exemples sont l'utilisation d'apikeys par des api. Je ne crois pas que l'utilisation de cookies ou d'authentification http soit admissible.

Mise à jour du 16 février 2019

L’approche mentionnée précédemment est essentiellement la suivante: "Identifiant du mot de passe du propriétaire de la ressource". type de subvention de OAuth2.0 . C'est un moyen facile de se mettre au travail. Cependant, avec cette approche, chaque application de l'organisation se verra dotée de ses propres mécanismes d'authentification et d'autorisation. L'approche recommandée est "Code d'autorisation". type de subvention. De plus, dans ma réponse précédente ci-dessous, je recommandais au navigateur localStorage de stocker les jetons d'authentification. Cependant, j'ai fini par croire que le cookie est la bonne option à cette fin. J'ai détaillé mes raisons, ma méthode d'implémentation de type d'autorisation de code d'autorisation, mes considérations de sécurité, etc. dans cette réponse StackOverflow .

Je pense que l'approche suivante peut être utilisée pour l'authentification du service REST:

  1. Créez une API de connexion RESTful pour accepter le nom d'utilisateur et le mot de passe pour l'authentification. Utiliser la méthode HTTP POST pour empêcher la mise en cache et SSL pour la sécurité pendant le transit En cas d'authentification réussie, l'API renvoie deux JWT: un jeton d'accès (validité plus courte, disons 30 minutes) et un jeton d'actualisation (validité plus longue, disons 24 heures)
  2. Le client (une interface Web) stocke les fichiers JWT dans un stockage local et, lors de chaque appel ultérieur de l'API, transmet le jeton d'accès sous "Authorization: Bearer #access token". en-tête
  3. L'API vérifie la validité du jeton en vérifiant la signature et la date d'expiration. Si le jeton est valide, vérifiez si l'utilisateur (il interprète la réclamation "sous" dans JWT en tant que nom d'utilisateur) a accès à l'API avec une recherche dans le cache. Si l'utilisateur est autorisé à accéder à l'API, exécutez la logique applicative
  4. Si le jeton a expiré, l'API renvoie le code de réponse HTTP 400
  5. À la réception du message 400/401, le client appelle une autre API REST avec le jeton d'actualisation indiqué dans "Autorisation: Bearer #refresh token". en-tête pour obtenir un nouveau jeton d'accès.
  6. À la réception de l'appel avec jeton d'actualisation, vérifiez si le jeton d'actualisation est valide en vérifiant la signature et la date d'expiration. Si le jeton d'actualisation est valide, actualisez le cache de droits d'accès de l'utilisateur à partir de la base de données et renvoyez un nouveau jeton d'accès et un jeton d'actualisation. Si le jeton d'actualisation n'est pas valide, renvoyez le code de réponse HTTP 400
  7. Si un nouveau jeton d'accès et un nouveau jeton d'actualisation sont renvoyés, passez à l'étape 2. Si le code de réponse HTTP 400 est renvoyé, le client suppose que le jeton d'actualisation a expiré et demande le nom d'utilisateur et le mot de passe de l'utilisateur
  8. Pour vous déconnecter, purgez le stockage local

Avec cette approche, nous effectuons la coûteuse opération consistant à charger le cache avec des informations de droits d'accès spécifiques à l'utilisateur toutes les 30 minutes. Ainsi, si un accès est révoqué ou qu'un nouvel accès est accordé, 30 minutes sont nécessaires pour réfléchir ou se déconnecter, suivi d'une connexion.

C’est le moyen de le faire: Utiliser OAuth 2.0 pour la connexion .

Vous pouvez utiliser d'autres méthodes d'authentification que celles de Google, à condition qu'elles prennent en charge OAuth.

Pour répondre à cette question, si j'ai bien compris ...

Un système d'authentification qui utilise REST afin que vous n'ayez pas besoin de suivre ou de gérer les utilisateurs de votre système. Ceci est fait en utilisant les méthodes HTTP POST, GET, PUT, DELETE. Nous prenons ces 4 méthodes et les considérons en termes d’interaction de base de données comme CREATE, READ, UPDATE, DELETE (mais sur le Web, nous utilisons POST et GET car c’est ce que les balises d'ancrage supportent actuellement). Donc, en traitant POST et GET comme notre CREATE / READ / UPDATE / DELETE (CRUD), nous pouvons concevoir des itinéraires dans notre application Web qui pourront déduire quelle action de CRUD nous accomplissons.

Par exemple, dans une application Ruby on Rails, nous pouvons créer notre application Web de telle sorte que si un utilisateur connecté se connecte http://store.com/account/logout , l’objet GET de cette page peut être considéré comme l’utilisateur qui tente de se déconnecter. Dans notre contrôleur de rails, nous construisons une action qui déconnecte l'utilisateur et le renvoie à la page d'accueil.

Un OBTENIR sur la page de connexion donnerait un formulaire. un POST sur la page de connexion serait considéré comme une tentative de connexion et prendrait les données du POST et les utiliserait pour se connecter.

Pour moi, il est courant d'utiliser des méthodes HTTP associées à la signification de leur base de données, puis de construire un système d'authentification en gardant à l'esprit que vous n'avez pas besoin de faire suivre les identifiants de session ni les sessions de suivi.

J'apprends encore - si vous trouvez quelque chose que j'ai dit qui ne va pas, corrigez-moi, et si vous en savez plus, postez-le ici. Merci.

L'utilisation d'une infrastructure de clé publique dans laquelle l'enregistrement d'une clé implique une liaison appropriée garantit que la clé publique est liée à l'individu auquel elle est affectée de manière à garantir la non-répudiation

Voir http://en.wikipedia.org/wiki/Public_key_infrastructure . Si vous suivez les normes PKI appropriées, la personne ou l'agent qui utilise la clé volée de manière inappropriée peut être identifié et verrouillé. Si l'agent est tenu d'utiliser un certificat, la liaison devient assez étroite. Un voleur intelligent et rapide peut s'échapper, mais il laisse plus de miettes.

Conseils valables pour la sécurisation de toute application Web

Si vous souhaitez sécuriser votre application, , vous devez absolument commencer par utiliser HTTPS au lieu de HTTP , afin de garantir la création d'un canal sécurisé entre vous et & amp; les utilisateurs qui empêcheront de renifler les données renvoyées & amp; en avant aux utilisateurs et amp; contribuera à préserver la confidentialité des données échangées.

Vous pouvez utiliser des JWT (jetons Web JSON) pour sécuriser les API RESTful . Cela présente de nombreux avantages par rapport aux sessions côté serveur. Les avantages sont principalement:

1- Plus évolutif, car vos serveurs d'API n'auront pas à gérer de sessions pour chaque utilisateur (ce qui peut être un lourd fardeau lorsque vous avez plusieurs sessions)

2- Les JWT sont autonomes & amp; avoir les revendications qui définissent le rôle d'utilisateur par exemple & amp; ce à quoi il peut accéder & amp; délivré à la date & amp; date d'expiration (après laquelle JWT ne sera plus valide)

3- Plus facile à gérer entre les équilibreurs de charge & amp; Si vous avez plusieurs serveurs API car vous n'avez pas besoin de partager les données de la session ni de configurer le serveur pour acheminer la session vers le même serveur, chaque fois qu'une demande adressée à un serveur JWT frappe un serveur, elle peut être authentifiée. autorisé

4- Moins de pression sur votre base de données, sans qu'il soit nécessaire de toujours stocker & amp; récupérer l'identifiant de session & amp; données pour chaque demande

5- Les JWT ne peuvent pas être altérés si vous utilisez une clé forte pour signer le JWT, vous pouvez donc faire confiance aux revendications dans le JWT envoyé avec la demande sans avoir à vérifier la session utilisateur & amp; qu'il soit autorisé ou non, il vous suffit de vérifier l'état de JWT & amp; alors vous êtes tous prêts à savoir qui & amp; ce que cet utilisateur peut faire.

De nombreuses bibliothèques offrent des moyens simples de créer & amp; validez les JWT dans la plupart des langages de programmation, par exemple: dans node.js, l’un des plus populaires est jsonwebtoken

Les API REST ayant généralement pour objectif de conserver le serveur sans état, les JWT sont donc davantage compatibles avec ce concept , car chaque demande est envoyée avec un jeton d'autorisation autonome (JWT) sans que le serveur ait à garder une trace de la session utilisateur par rapport aux sessions qui rendent le serveur en état de manière à ce qu'il se souvienne de l'utilisateur & amp; son rôle, cependant, les sessions sont également largement utilisées & amp; ont leurs avantages, que vous pouvez rechercher si vous le souhaitez.

Une chose importante à noter est que vous devez livrer le JWT en toute sécurité au client en utilisant HTTPS & amp; enregistrez-le dans un endroit sécurisé (par exemple, dans un stockage local).

Pour en savoir plus sur les JWT, depuis ce lien

.
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top