Comment gérer l'authentification dans une architecture client-serveur RESTful 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 sur HTTPS;
- Cookies et gestion de session;
- 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 encore mieux mélanger ces techniques, pour correspondre au mieux à votre architecture logicielle.
Chaque schéma d'authentification a ses propres avantages et 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 HTTPS standard, 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 à implémenter, disponible par défaut sur tous les navigateurs, mais présente certains inconvénients connus, comme la terrible fenêtre d'authentification affichée sur le navigateur, qui persistera (il n'y a pas de fonctionnalité de type LogOut ici), une consommation supplémentaire de CPU 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 uniquement côté client, lors de la saisie au clavier, et être stocké en tant que hachage sécurisé sur le serveur) .
Nous pouvons utiliser l' authentification Digest , mais elle nécessite également HTTPS, car elle est vulnérable aux attaques MiM ou 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 sans état.
Une possibilité pourrait être de conserver toutes les données dans le contenu des cookies. Et, par conception, le cookie est géré côté serveur (le client, en fait, n'essaie même pas d'interpréter ces données de cookie: il les restitue simplement au serveur à chaque demande successive). Mais ces données de cookie sont des données d'état d'application, donc le client doit les gérer, pas le serveur, dans un monde sans état pur.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
La technique des cookies elle-même est liée à HTTP, donc ce n'est pas vraiment RESTful, qui devrait être indépendant du protocole, à mon humble avis. Il est vulnérable aux attaques MiM ou Replay .
Accordé via Token (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 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 bref, cela est très similaire à un cookie et souffre des mêmes problèmes: pas apatride, s'appuyant sur les détails de transmission HTTP et soumis à de nombreuses faiblesses de sécurité - y compris MiM et Replay - ne doit donc être utilisé que via HTTPS. En règle générale, un JWT est utilisé comme un jeton.
Authentification de requête
L'authentification de requête consiste à signer chaque demande 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 en signant les paramètres de requête triés dans l'ordre alphabétique en minuscules en utilisant les informations d'identification privées comme jeton de signature. La signature doit avoir lieu avant que l'URL n'encode la 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 à partir du lien ci-dessus:
GET /object?apiKey=Qwerty2010
doivent être transmis comme tels:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
La chaîne en cours de signature est /object?apikey=Qwerty2010×tamp=1261496500et la signature est le hachage SHA256 de cette chaîne à l'aide du composant privé de la clé 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 URI. L'ajout de ce paramètre supplémentaire ne rompt donc pas le mécanisme de cache.
Consultez cet article pour plus de détails sur l'authentification RESTful dans notre infrastructure client-serveur ORM / SOA / MVC, basée sur JSON et REST. Étant donné que nous autorisons la communication non seulement via HTTP / 1.1, mais également les canaux nommés ou les messages GDI (localement), nous avons essayé d'implémenter un modèle d'authentification véritablement RESTful, et de ne pas compter sur la spécificité HTTP (comme l'en-tête ou les cookies).
Remarque ultérieure : l'ajout d'une signature dans l'URI peut être considéré comme une mauvaise pratique (car, par exemple, elle apparaîtra dans les journaux du serveur http), elle doit donc être atténuée, par exemple par un TTL approprié pour éviter les relectures. Mais si vos journaux http sont compromis, vous aurez certainement de plus gros problèmes de sécurité.
Dans la pratique, la prochaine authentification des jetons MAC pour OAuth 2.0 pourrait être une énorme amélioration par rapport au schéma actuel "Accordé par jeton". Mais c'est toujours 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 implémenté sur HTTP. REST peut utiliser d'autres couches de communication. Ainsi, une authentification RESTful n'est pas seulement synonyme d'authentification HTTP, quelles que soient les réponses de Google. Il ne doit même pas utiliser du tout le mécanisme HTTP mais doit être abstrait de la couche de communication. Et si vous utilisez la communication HTTP, grâce à l' initiative Let's Encrypt, il n'y a aucune raison de ne pas utiliser le HTTPS approprié, qui est requis en plus de tout schéma d'authentification.