Authentification RESTful

Question

Que signifie l'authentification RESTful et comment fonctionne-t-elle ? Je n'arrive pas à trouver un bon aperçu sur Google. Tout ce que je comprends, c'est que vous passez la clé de session (remeberal) dans l'URL, mais cela pourrait être terriblement faux.

Answer 1

La façon de gérer l'authentification dans une architecture client-serveur RESTful est un sujet de débat.

En général, cela peut être réalisé, dans le monde de la SOA sur HTTP, via :

• Authentification de base HTTP sur HTTPS ;
• Cookies et gestion des sessions ;
• Jeton dans les en-têtes HTTP (ex. OAuth 2.0 + JWT) ;
• Authentification des requêtes avec des paramètres de signature supplémentaires.

Vous devrez adapter, ou mieux encore mélanger ces techniques, pour qu'elles correspondent au mieux à votre architecture logicielle.

Chaque schéma d'authentification a ses avantages et ses inconvénients, 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==

Elle est facile à mettre en œuvre, disponible par défaut sur tous les navigateurs, mais présente quelques inconvénients connus, comme l'affreuse fenêtre d'authentification affichée sur le navigateur, qui persistera (il n'y a pas de fonction de type déconnexion ici), une certaine consommation supplémentaire de CPU côté serveur, et le fait que le nom d'utilisateur et le mot de passe sont transmis (par HTTPS) au serveur (il devrait être plus sûr de laisser le mot de passe uniquement du côté client, lors de la saisie au clavier, et d'être stocké sous forme de hachage sécurisé sur le serveur).

Nous pouvons utiliser Authentification Digest mais il faut également utiliser le protocole HTTPS, car il est vulnérable à l'infection par le VIH. MiM o Replay et est spécifique à HTTP.

Session via les cookies

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

Une possibilité serait de conserver toutes les données dans le contenu du cookie. Et, par conception, le cookie est géré du côté du serveur (le client, en fait, n'essaie même pas d'interpréter ces données de cookie : il se contente de les renvoyer au serveur à chaque demande successive). Mais ces données de cookie sont des données d'état d'application, et c'est donc le client qui doit les gérer, et non le serveur, dans un monde purement Stateless.

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

La technique des cookies est elle-même liée au protocole HTTP, ce qui n'est pas vraiment RESTful, qui devrait être indépendant du protocole, à mon avis. Elle est vulnérable à MiM o Replay attaques.

Accordé via Token (OAuth2)

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

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

En bref, il est très similaire à un cookie et souffre des mêmes problèmes : il n'est pas apatride, repose sur les détails de la transmission HTTP et est sujet à beaucoup de failles de sécurité - y compris MiM et Replay - et ne doit donc être utilisé que via HTTPS. En règle générale, un JWT est utilisé comme un jeton.

Authentification des requêtes

L'authentification des requêtes consiste à signer chaque requête RESTful via certains 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 par la signature des paramètres de la requête triés en minuscules, par ordre alphabétique, en utilisant le justificatif d'identité privé comme jeton de signature. La signature doit avoir lieu avant le codage URL de la de la requête.

Cette technique est peut-être la plus compatible avec une architecture sans état, et peut également être mise en œuvre avec une gestion légère des sessions (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 provenant du lien ci-dessus :

GET /object?apiKey=Qwerty2010

doit être transmis comme tel :

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

La chaîne de caractères à signer est /object?apikey=Qwerty2010&timestamp=1261496500 et la signature est le hachage SHA256 de cette chaîne en utilisant le composant privé de la clé API.

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

Ver cet article pour plus de détails sur l'authentification RESTful dans notre cadre ORM/SOA/MVC client-serveur, basé sur JSON et REST. Comme nous autorisons la communication non seulement via HTTP/1.1, mais aussi via des pipes nommés ou des messages GDI (localement), nous avons essayé d'implémenter un modèle d'authentification véritablement RESTful, et de ne pas dépendre des spécificités HTTP (comme les en-têtes ou les cookies).

Note ultérieure L'ajout d'une signature dans l'URI peut être considéré comme une mauvaise pratique (puisqu'elle apparaîtra par exemple dans les journaux du serveur http) et doit donc être atténué, par exemple par un TTL approprié pour éviter les répétitions. Mais si vos journaux http sont compromis, vous aurez certainement de plus gros problèmes de sécurité.

En pratique, les prochaines Authentification par jetons MAC pour OAuth 2.0 peut constituer une amélioration considérable par rapport au système actuel de "concession par jeton". Mais il s'agit encore d'un travail en cours et il 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 aussi principalement mis en œuvre sur HTTP. REST peut utiliser d'autres couches de communication. Ainsi, une authentification RESTful n'est pas seulement un synonyme d'authentification HTTP, quoi que réponde Google. Elle devrait même ne pas utiliser du tout le mécanisme HTTP mais être abstraite de la couche de communication. Et si vous utilisez la communication HTTP, grâce à la fonction Initiative Let's Encrypt il n'y a aucune raison de ne pas utiliser le protocole HTTPS, qui est requis en plus de tout système d'authentification.

Answer 2

Je doute que les personnes qui crient avec enthousiasme "Authentification HTTP" aient jamais essayé de créer une application basée sur un navigateur (au lieu d'un service web de machine à machine) avec REST (sans vouloir vous offenser - je pense simplement qu'ils n'ont jamais été confrontés aux complications).

Les problèmes que j'ai trouvés en utilisant l'authentification HTTP sur les services RESTful qui produisent des pages HTML à afficher dans un navigateur sont les suivants :

• l'utilisateur se retrouve généralement face à une boîte de connexion laide, créée par un navigateur, qui est très peu conviviale. il n'est pas possible d'ajouter la récupération du mot de passe, des boîtes d'aide, etc.
• se déconnecter ou se connecter sous un autre nom est un problème - les navigateurs continueront à envoyer des informations d'authentification au site jusqu'à ce que vous fermiez la fenêtre.
• les temps morts sont difficiles

Un article très perspicace qui aborde ces questions point par point est le suivant aquí mais il en résulte une lot de piratage javascript spécifique au navigateur, de solutions de contournement pour les solutions de contournement, etc. En tant que tel, il n'est pas non plus compatible avec l'avenir et nécessitera une maintenance constante lors de la sortie de nouveaux navigateurs. Je ne considère pas qu'il s'agit d'une conception propre et claire, et je pense que c'est beaucoup de travail supplémentaire et de maux de tête juste pour pouvoir montrer avec enthousiasme mon badge REST à mes amis.

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

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

• A session fait correspondre une clé à un identifiant d'utilisateur (et éventuellement un horodatage de dernière action pour les délais)
• Si un session existe, alors cela signifie que la clé est valide.
• Se connecter signifie POSTing à /sessions, une nouvelle clé est définie comme un cookie.
• Se déconnecter signifie SUPPRIMER /sessions/{key} (avec le POST surchargé, n'oubliez pas que nous sommes un navigateur et que le HTML 5 a encore beaucoup de chemin à parcourir).
• L'authentification se fait 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 avec l'authentification HTTP, maintenant, est que la clé d'authentification est générée par le serveur et envoyée au client qui la renvoie sans cesse, au lieu que le client la calcule à partir des informations d'identification saisies.

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

Je pense que c'est 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 du cookie est simplement utilisé pour adresser une ressource côté serveur, tout comme un accept-language pourrait être utilisé pour accéder à des ressources de traduction, etc. Je pense que c'est la même chose, mais peut-être que d'autres ne le pensent pas ? Qu'en pensez-vous ?

Answer 3

Beaucoup de choses ont déjà été dites sur ce sujet par les bonnes personnes ici. Mais voici mes deux cents.

Il existe 2 modes d'interaction :

1. l'homme à la machine (HTM)
2. machine-à-machine (MTM)

La machine est le dénominateur commun, exprimé sous forme d'API REST, et les acteurs/clients sont soit des humains, soit des machines.

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

Si l'on considère cela dans le contexte des applications homme-machine, "basées sur un navigateur" comme le souligne M. Skrebbel ci-dessus, cela signifie que l'application (web) exécutée dans le navigateur devra envoyer son état et les informations pertinentes à chaque requête qu'elle fera aux API REST du back-end.

Considérez ceci : Vous disposez d'une plateforme de données/d'informations exposée à l'actif des API REST. Vous disposez peut-être d'une plateforme de BI en libre-service qui gère tous les cubes de données. Mais vous voulez que vos clients (humains) y accèdent via (1) une application web, (2) une application mobile et (3) une application tierce. En fin de compte, même la chaîne des MTMs mène au HTM - d'accord. Les utilisateurs humains restent donc au sommet de la chaîne d'information.

Dans les deux premiers cas, il s'agit d'une interaction homme-machine, l'information étant effectivement consommée par un utilisateur humain. Dans le dernier cas, c'est un programme machine qui consomme les API REST.

Le concept d'authentification s'applique à tous les domaines. Comment allez-vous le concevoir pour que l'accès à vos API REST se fasse de manière uniforme et sécurisée ? D'après moi, il y a deux façons de procéder :

Way-1 :

1. Il n'y a pas de connexion, pour commencer. Chaque requête effectue la connexion
2. Le client envoie ses paramètres d'identification + les paramètres spécifiques à la demande. avec chaque demande
3. L'API REST les prend, fait demi-tour, envoie un ping au magasin d'utilisateurs (quel qu'il soit) et confirme l'authentification
4. Si l'authentification est établie, la demande est traitée ; sinon, elle est refusée. avec le code d'état HTTP approprié
5. Répétez ce qui précède pour chaque requête de toutes les API REST de votre catalogue

Way-2 :

1. Le client commence par une demande d'authentification
2. Une API REST de connexion traitera toutes ces demandes.
3. Il prend les paramètres d'authentification (clé API, uid/pwd ou tout ce que vous choisissez) et vérifie l'authentification par rapport à la base de données des utilisateurs (LDAP, AD, ou MySQL DB, etc.).
4. S'il est vérifié, il crée un jeton d'authentification et le remet au client/appelant
5. L'appelant envoie ensuite ce jeton d'authentification + les paramètres spécifiques de la demande avec chaque demande ultérieure à d'autres API REST d'entreprise, jusqu'à la déconnexion ou l'expiration du bail.

Il est clair que dans Way-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 et, par conséquent, cette "clé de validation" doit être reconnue par les autres API REST de votre catalogue.

Cela signifie, bien entendu, que la clé/le jeton d'authentification devra être stocké(e) et partagé(e) entre les API REST. Ce dépôt de jetons partagé et fiable peut être local ou 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" (concernant le statut d'authentification 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 soit effectué pour toutes les demandes entrantes.

L'authentification est un processus gourmand en ressources. Imaginez l'exécution de requêtes SQL, pour chaque demande entrante, dans votre magasin d'utilisateurs pour vérifier la correspondance uid/pwd. Ou encore, pour chiffrer et effectuer des correspondances de hachage (à la manière d'AWS). Et d'un point de vue architectural, chaque API REST devra effectuer cette opération, je suppose, en utilisant un service de connexion back-end commun. Parce que, si vous ne le faites pas, alors vous dispersez le code d'authentification partout. Un grand désordre.

Donc plus il y a de couches, plus il y a de latence.

Maintenant, prenez la méthode 1 et appliquez-la à HTM. Votre utilisateur (humain) se soucie-t-il vraiment de devoir envoyer uid/pwd/hash ou autre avec chaque requête ? Non, tant que vous ne l'ennuyez pas en lançant la page d'authentification/login toutes les secondes. Bonne chance pour avoir des clients si vous le faites. Donc, ce que vous allez faire, c'est stocker les informations de connexion quelque part du côté client, dans le navigateur, dès le début, et les envoyer avec chaque requête effectuée. Pour l'utilisateur (humain), il s'est déjà connecté, et une "session" est disponible. Mais en réalité, elle est authentifiée à chaque demande.

Même chose pour 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, comme il s'agit d'une machine, nous pouvons l'ennuyer en lui demandant de soumettre des informations d'authentification à chaque demande. Tout le monde s'en fout ! Appliquer la méthode 2 à MTM ne suscitera aucune réaction particulière ; c'est une foutue machine. Elle s'en moque éperdument !

La question est donc de savoir ce qui convient le mieux à vos besoins. L'apatridie a un prix à payer. Payez ce prix et passez à autre chose. Si vous voulez être un puriste, payez-en le prix également et passez à autre chose.

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

Answer 4

Voici une solution d'authentification réellement et complètement RESTful :

1. Créez une paire de clés publiques/privées sur le serveur d'authentification.

2. Distribuez la clé publique à tous les serveurs.

3. Quand un client s'authentifie :

   3.1. émettre un jeton qui contient les éléments suivants :

   • Délai d'expiration
   • nom des utilisateurs (facultatif)
   • IP des utilisateurs (facultatif)
   • hachage d'un mot de passe (facultatif)

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

   3.3. Renvoyer 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.

Il s'agit d'une authentification apatride/RESTful.

Notez que si un hachage du mot de passe était inclus, l'utilisateur enverrait également le mot de passe non crypté avec le jeton d'authentification. Le serveur pourrait vérifier que le mot de passe correspond à celui qui a été 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. Javascript du côté client pourrait se charger d'obtenir le mot de passe de l'utilisateur et de le stocker côté client, soit en mémoire, soit dans un cookie, éventuellement crypté avec le mot de passe du serveur. public clé.

Answer 5

Avant tout, un service web RESTful est STATELESS (ou en d'autres termes, SESSIONLESS ). Par conséquent, un service RESTful n'a pas et ne devrait pas avoir de concept de session ou de cookies. La façon de procéder à l'authentification ou à l'autorisation dans un service RESTful est d'utiliser l'en-tête d'autorisation HTTP tel que défini dans les spécifications HTTP RFC 2616. Chaque demande doit contenir l'en-tête d'autorisation HTTP, et la demande doit être envoyée via une connexion HTTPs (SSL). C'est la façon correcte de procéder à l'authentification et à la vérification de l'autorisation des demandes dans un service Web RESTful HTTP. 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 mis en œuvre l'authentification/autorisation.