Comment sécuriser les services web RESTful ?

Question

Je dois mettre en place un système sécurisé Services web RESTful . J'ai déjà fait quelques recherches sur Google mais je suis bloqué.

Options :

TLS (HTTPS) +

• HTTP Basic (pc1oad1etter)
• HTTP Digest
• à deux pattes OAuth
• une approche basée sur les cookies
• certificats de clients (Tom Ritter et aquí )
• Demandes signées en utilisant HMAC y une vie limitée

Y a-t-il d'autres options possibles à envisager ? Si OAuth, quelle version ? Est-ce même important ? D'après ce que j'ai lu jusqu'à présent OAuth 2.0 avec des jetons au porteur (c'est-à-dire sans signature) semble être insécurité .

J'ai trouvé un autre article très intéressant sur Authentification basée sur REST .

Sécurisez votre API REST... La bonne méthode

Answer 1

Il y a une autre méthode, très sûre. Ce sont les certificats des clients. Vous savez comment les serveurs présentent un Cert SSL lorsque vous les contactez sur https ? Eh bien, les serveurs peuvent demander un certificat à un client afin de savoir si ce dernier est bien celui qu'il prétend être. Les clients génèrent des certificats et vous les remettent par le biais d'un canal sécurisé (par exemple en se présentant à votre bureau avec une clé USB - de préférence une clé USB non-trojanée).

Vous chargez le clé publique du certificat (et le(s) certificat(s) de leur signataire, si nécessaire) dans votre serveur web, et le serveur web n'acceptera pas de connexions de la part de quiconque sauf les personnes qui ont les clés privées correspondantes pour les certitudes qu'il connaît. Il s'exécute sur la couche HTTPS, ce qui vous permet d'éviter complètement l'authentification au niveau de l'application comme OAuth (selon vos besoins). Vous pouvez faire abstraction d'une couche et créer une autorité de certification locale et signer les demandes de certificat des clients, ce qui vous permet d'éviter les étapes "les faire venir au bureau" et "charger les certificats sur le serveur".

Une douleur au cou ? Absolument. Bon pour tout ? Non. Très sûr ? Ouaip.

Cependant, il faut que les clients gardent leurs certificats en sécurité (ils ne peuvent pas publier leurs clés privées en ligne), et il est généralement utilisé lorsque vous vendez un service aux clients plutôt que de laisser n'importe qui s'inscrire et se connecter.

Quoi qu'il en soit, ce n'est peut-être pas la solution que vous recherchez (pour être honnête, ce n'est probablement pas le cas), mais c'est une autre option.

Answer 2

HTTP Basic + HTTPS est une méthode courante.

Answer 3

Si vous devez choisir entre plusieurs versions d'OAuth, optez pour OAuth 2.0.

Les jetons porteurs OAuth ne doivent être utilisés qu'avec un transport sécurisé.

Les jetons de porteur OAuth sont aussi sûrs ou non que le transport qui chiffre la conversation. HTTPS prend en charge la protection contre les attaques par rejeu, il n'est donc pas nécessaire que le jeton porteur soit également protégé contre les rejeux.

S'il est vrai que si quelqu'un intercepte votre jeton de porteur, il peut se faire passer pour vous lors de l'appel de l'API, il existe de nombreux moyens d'atténuer ce risque. Si vous donnez à vos jetons une longue période d'expiration et que vous attendez de vos clients qu'ils stockent les jetons localement, vous avez un plus grand risque que les jetons soient interceptés et utilisés à mauvais escient que si vous donnez à vos jetons une courte période d'expiration, que vous demandez aux clients d'acquérir de nouveaux jetons pour chaque session et que vous conseillez aux clients de ne pas conserver les jetons.

Si vous devez sécuriser des charges utiles qui passent par plusieurs participants, vous avez besoin de quelque chose de plus que HTTPS/SSL, puisque HTTPS/SSL ne chiffre qu'un seul lien du graphe. Ce n'est pas un défaut d'OAuth.

Les jetons au porteur sont faciles à obtenir pour les clients, faciles à utiliser pour les appels d'API et sont largement utilisés (avec HTTPS) pour sécuriser les API publiques de Google, Facebook et de nombreux autres services.