web-dev-qa-db-fra.com

Authentification RESTful

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.

restauthenticationrestful-authenticationrest-security
693
Jim Keener

Comment gérer l'authentification dans une architecture RESTful Client-Server est un sujet de débat.

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

  • Authentification de base HTTP via 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, voire 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 de base HTTP sur HTTPS

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

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

Il est 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’ya pas de fonctionnalité semblable à LogOut ici), une certaine consommation supplémentaire de ressources processeur côté serveur, 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é sous forme de hachage sécurisé sur le serveur) .

Nous pouvons utiliser Authentification Digest , mais cela nécessite également HTTPS, car il est vulnérable aux attaques MiM ou Replay , et est spécifique à HTTP.

Session via 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 transmet 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, IMHO. Il est vulnérable aux attaques de { MiM _ ou _ {{Replay)} _.

Accordé par jeton (OAuth2)

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

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

En bref, 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 sujet à beaucoup de faiblesses en matière de sécurité - y compris MiM et Replay - utilisé uniquement sur HTTPS. En règle générale, un JWT est utilisé comme jeton.

Authentification de 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 l'URL encodant le fichier chaîne de requête.

Cette technique est peut-être la plus compatible avec une architecture sans état, et peut également être implémentée avec une gestion de session légère (en utilisant des sessions en mémoire au lieu de la persistance de la base de données).

Par exemple, voici un exemple d’URI générique tiré du lien ci-dessus:

GET /object?apiKey=Qwerty2010

devrait être transmis en tant que tel:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

La chaîne en cours de signature est /object?apikey=Qwerty2010&timestamp=1261496500 et la signature est le hachage SHA256 de cette chaîne à l'aide du composant privé de la clé d'API.

La mise en cache des données côté serveur peut être toujours disponible. Par exemple, dans notre framework, nous mettons en cache les réponses au niveau SQL, pas au niveau des URI. L'ajout de ce paramètre supplémentaire ne rompt donc pas le mécanisme de cache.

Voir cet article pour plus d'informations sur l'authentification RESTful dans notre infrastructure client-serveur ORM/SOA/MVC, basée sur JSON et REST. Etant donné que nous autorisons la communication non seulement via HTTP/1.1, mais également avec les canaux nommés ou les messages GDI (localement), nous avons essayé d'implémenter un modèle d'authentification véritablement RESTful, sans faire appel à la spécificité HTTP (type en-tête ou cookies).

Plus tard Note: l'ajout d'une signature dans l'URI peut être considéré comme une mauvaise pratique (car, par exemple, il figurera dans les journaux du serveur http), il faut donc l'atténuer, par exemple. par un TTL approprié pour éviter les rediffusions. Mais si vos journaux http sont compromis, vous aurez certainement de plus gros problèmes de sécurité.

En pratique, le prochain { authentification des jetons MAC pour OAuth 2.0 } peut représenter une énorme amélioration par rapport au schéma actuel "Accordé par jeton". Mais cela reste un travail en cours et est lié à la transmission HTTP.Conclusion.

Il convient de conclure que REST n’est pas uniquement basé sur HTTP, même si, dans la pratique, il est également principalement mis en œuvre sur HTTP. REST peut utiliser d'autres couches de communication. Ainsi, une authentification RESTful n'est pas simplement synonyme d'authentification HTTP, quelles que soient les réponses de Google. Il ne devrait même pas du tout utiliser le mécanisme HTTP, mais doit être extrait de la couche de communication. Et si vous utilisez la communication HTTP, grâce à la initiative Let's Encrypt , il n'y a aucune raison de ne pas utiliser le protocole HTTPS approprié, qui est requis en plus de tout schéma d'authentification.

It's worth concluding that REST is not only HTTP-based, even if, in practice, it's also mostly implemented over HTTP. REST can use other communication layers. So a RESTful authentication is not just a synonym of HTTP authentication, whatever Google answers. It should even not use the HTTP mechanism at all but shall be abstracted from the communication layer. And if you use HTTP communication, thanks to the Let's Encrypt initiative there is no reason not to use proper HTTPS, which is required in addition to any authentication scheme.

542
Arnaud Bouchez

Je doute que les gens criant avec enthousiasme "Authentification HTTP" aient déjà 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 l'aient jamais fait fait face aux complications).

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

  • l’utilisateur obtient généralement une boîte de connexion laide faite par un navigateur, ce 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.
  • se déconnecter ou se connecter sous un autre nom 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 article très perspicace qui aborde ces problèmes point par point est ici , mais cela se traduit par un lot de hackery javascript spécifique au navigateur, de solutions de contournement pour des solutions de contournement, etc. 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, et en plus, je pense 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 les informations d'authentification HTTP. Conceptuellement, la seule différence est que le contenu de cet élément de l'état 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:

  • Un session associe une clé à un ID utilisateur (et éventuellement à un horodatage de dernière action pour les délais d'expiration)
  • Si un session existe, cela signifie que la clé est valide.
  • Login signifie POSTing à/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 que c'est une solution suffisante qui fonctionne, mais je dois avouer 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 les mêmes. 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 penses-tu, les gars?

410
skrebbel

On en a déjà assez dit ici sur ce sujet. Mais voici mes 2 cents. 

Il y a 2 modes d'interaction:

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

La machine est le dénominateur commun, exprimé sous la forme d'API REST, et les acteurs/clients étant les humains ou les machines.

Dans une architecture véritablement REST, le concept d'apatridie 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 le souligne Skrebbel, cela signifie que l'application (Web) exécutée dans le navigateur doit envoyer son état et des informations pertinentes à chaque demande. il se rend au back-end REST API. 

Considérez ceci: Vous avez un actif exposé d’API REST 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 de l'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, un programme d'ordinateur 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? La façon dont je vois cela, il y a 2 façons:

Way-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 + les paramètres spécifiques à la requête À chaque requête
  3. L'API REST les prend, se retourne, envoie une requête ping au magasin de l'utilisateur (Quoi que ce soit) et confirme l'autorisation.
  4. Si l’autorisation est établie, répond à la demande; sinon, refuse 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 de connexion REST traitera toutes ces demandes.
  3. Il prend les paramètres d'authentification (clé d'API, uid/pwd ou ce que vous choisissez À choisir) et vérifie l'authentification par rapport au magasin de l'utilisateur (LDAP, AD ou base de données 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 paramètre de jeton d'authentification + demande avec les paramètres À chaque demande ultérieure adressée à d'autres API REST de l'entreprise, jusqu'à sa déconnexion ou jusqu'à l'expiration du bail.

Clairement, 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 d'authentification. Par conséquent, cette "clé de service" doit être approuvée par les autres API REST de votre catalogue.

Bien entendu, cela signifie que la clé/le jeton d'autorisation 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. 

Le fait est qu'un "état" (relatif au statut authentifié du client) doit être maintenu et partagé afin que toutes les API REST puissent créer un cercle de confiance. Si nous ne le faisons pas, ce qui est 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 requête entrante, dans votre magasin d'utilisateurs pour vérifier la correspondance uid/pwd. Ou, pour chiffrer et effectuer des correspondances de hachage (style AWS). Et sur le plan architectural, chaque API REST devra effectuer ceci, je suppose, en utilisant un service de connexion back-end commun. Parce que, si vous ne le faites pas, vous écrasez le code d'autorisation partout. Un gros désordre. 

Donc plus de couches, plus de latence.

Maintenant, prenez Way-1 et appliquez-vous à HTM. Votre utilisateur (humain) se soucie-t-il vraiment de devoir envoyer uid/pwd/hash ou quoi que ce soit avec chaque demande? Non, tant que vous ne la dérangez pas en lançant la page auth/login à chaque seconde. Bonne chance d'avoir des clients si vous le faites. Par conséquent, vous allez stocker les informations de connexion quelque part sur le côté client, dans le navigateur, dès le début, et les envoyer avec chaque demande effectuée. Pour l'utilisateur (humain), elle s'est déjà connectée et une "session" est disponible. Mais en réalité, elle est authentifiée à chaque demande. 

Même avec Way-2. Votre utilisateur (humain) ne le remarquera jamais. Donc, aucun mal n'a été fait.Et si on appliquait Way-1 à MTM? Dans ce cas, puisque c'est une machine, nous pouvons ennuyer ce gars en lui demandant de fournir des informations d'authentification à chaque demande. Tout le monde s'en fout! Effectuer Way-2 sur MTM ne provoquera aucune réaction particulière; c'est une fichue machine. Il s'en fout!.

Alors vraiment, la question est ce qui convient à votre besoin. L'apatridie a un prix à payer. Payer le prix et passer à autre chose. Si vous voulez être un puriste, alors payez le prix pour cela aussi, et passez à autre chose.

En fin de compte, les philosophies importent peu. Ce qui compte vraiment, c'est la découverte d'informations, la présentation et l'expérience de consommation. Si les gens aiment vos API, vous avez fait votre travail. 

In the end, philosophies do not matter. What really matters is information discovery, presentation, and the consumption experience. If people love your APIs, you did your job.

133
Kingz

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 qui contient les éléments suivants:

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

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

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

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

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

C'est l'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 côté client, en mémoire ou dans un cookie, éventuellement chiffré avec la clé public du serveur.

48
jcoffland

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

L’approche RESTful est censée vous faciliter la vie et réduire les frais généraux et le coût des sessions, essayez de la suivre car c’est une chose sage à faire, mais à la minute où vous suivez une discipline (toute discipline/directive) à l’extrême ne fournit plus le bénéfice auquel il était destiné, alors 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 pour vous 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 composée d'une courte chaîne contenant une clé, quel est le problème?

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

36
arg20

Tout d’abord, un service Web RESTful estSANS ÉTAT(ou en d’autres termes,SANS SESSION). 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 doit être envoyée 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 des services 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.

32
user2213684

Il ne s'agit certainement pas de "clés de session", car 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 autoriser la demande seule sans aucun état d'application côté serveur.

La façon la plus simple de procéder consiste à utiliser les mécanismes d'authentification intégrés à HTTP dans RFC 2617 .

22
Justin Sheehy

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

Vous pouvez essayer de visiter la page (qui est censée être visible uniquement par les utilisateurs authentifiés) 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 vous refusez les États, vous devez utiliser le protocole HTTPS (c’est-à-dire laisser la question de la sécurité à un autre niveau).

15
Ji Han

Je pense que l'authentification reposante implique le passage d'un jeton d'authentification en tant que paramètre dans 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 qualifiée.

12
Bjorn Tipling

Mise à jour le 16 février 2019

L'approche mentionnée précédemment ci-dessous est essentiellement le type d'octroi "Identifiant de mot de passe du propriétaire de la ressource" 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 le type de subvention "Code d'autorisation". 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, l'approche de mise en œuvre du type d'autorisation de code d'autorisation, les considérations de sécurité, etc. dans cette réponse StackOverflow .

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

  1. Créez une API de connexion RESTful pour accepter le nom d'utilisateur et le mot de passe pour l'authentification. Utilisez la méthode HTTP POST pour empêcher la mise en cache et SSL pour la sécurité lors du transit .__ En cas d’authentification réussie, l’API renvoie deux JWT: un jeton d’accès (validité plus courte, par exemple 30 minutes) et un jeton d’actualisation (validité plus 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 dans l'en-tête "Authorization: Bearer #access token".
  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 revendication "sous" dans JWT comme un 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 métier.
  4. Si le jeton a expiré, l'API renvoie le code de réponse HTTP 400
  5. Lors de la réception du message 400/401, le client appelle une autre API REST avec le jeton d'actualisation indiqué dans l'en-tête "Authorization: Bearer #refresh token" 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 de chargement du cache avec des informations détaillées sur les 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é, il faut 30 minutes pour réfléchir ou une déconnexion suivie d'un identifiant.

10
Saptarshi Basu

Voici comment procéder: Utiliser OAuth 2.0 pour la connexion .

Vous pouvez utiliser d'autres méthodes d'authentification que Google, à condition que cette dernière prenne en charge OAuth.

8
moshe beeri

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 respectez 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.

2
DonB.

Pour répondre à cette question de ma compréhension ...

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). Ainsi, 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 , alors le GET de cette page peut s'afficher sous la forme suivante: utilisateur essayant de se déconnecter. Dans notre contrôleur Rails, nous construisons une action qui déconnecte l'utilisateur et le renvoie à la page d'accueil.

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

Pour moi, il est courant d’utiliser des méthodes HTTP mappées sur leur signification de base de données, puis de construire un système d’authentification en gardant à l’esprit que vous n’avez pas besoin de passer d’identifiant de session ni de session 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.

2
mike

Conseils valables pour sécuriser une application Web

Si vous voulez sécuriser votre application, vous devez absolument commencer par utiliser HTTPS au lieu de HTTP, cela crée un canal sécurisé entre vous et les utilisateurs qui empêchera de renifler les données aux utilisateurs et contribuera à maintenir 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 principaux avantages sont les suivants:

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 et ont les revendications qui définissent le rôle de l'utilisateur, par exemple, et ce à quoi il peut accéder et émis à la date et la date d'expiration (après quoi JWT ne sera plus valide).

3- Plus facile à gérer entre les équilibreurs de charge et 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 peut être authentifiée. & autorisé

4- Moins de pression sur votre base de données et plus besoin de stocker et de récupérer en permanence les identifiants de session et les 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 de l'utilisateur et s'il est autorisé ou non. , vous pouvez simplement vérifier le JWT et vous êtes prêt à savoir qui et ce que cet utilisateur peut faire.

De nombreuses bibliothèques offrent des moyens simples de créer et de valider des JWT dans la plupart des langages de programmation, par exemple: dans node.js, l'un des plus populaires est jsonwebtoken

Puisque REST, les API ont 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 dynamique, de sorte qu'il se souvienne de l'utilisateur et de son rôle; toutefois, les sessions sont également largement utilisées et disposent de 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 et le sauvegarder dans un endroit sécurisé (par exemple, dans un stockage local).

Vous pouvez en apprendre plus sur JWTs à partir de ce lien

1
Ahmed Elkoussy