88 votes

Comment sécuriser les services Web RESTful?

J'ai pour sécuriser des services web RESTful. J'ai déjà fait quelques recherches à l'aide de Google, mais je suis bloqué.

Options:

TLS (HTTPS) +

Il n'y a plus d'options possibles à prendre en considération? Si OAuth alors quelle version? Est-il encore de l'importance? De ce que j'ai lu jusqu'à présent protocole OAuth 2.0 avec le porteur de jetons (qui est sans signatures) semble être en insécurité.

J'ai trouvé un autre article très intéressant sur le RESTE de l'authentification basée sur.

Sécuriser Votre API REST... Le bon sens

58voto

Tom Ritter Points 44352

Il y a une autre méthode sûre. C'est de certificats client. Savoir comment les serveurs de présenter un certificat SSL lorsque vous communiquez avec eux sur https? Bien que les serveurs puissent demander un cert à partir d'un client afin qu'ils sachent le client est en fait qui ils disent qu'ils sont. Les Clients de générer les certificats et les donner à vous sur un canal sécurisé (comme à venir dans votre bureau avec une clé USB, de préférence un non-trojaned clé USB).

De charger la clé publique de l'cert, certificats clients (et leur le certificat du signataire(s), si nécessaire) sur votre serveur web et le serveur web n'accepte pas les connexions de personne , sauf les gens qui ont le correspondant clés privées pour la certs il connaît. Il fonctionne sur la couche HTTPS, vous pouvez même être en mesure de complètement ignorer l'authentification de niveau application comme OAuth (selon vos besoins). Vous pouvez résumé une couche de loin et de créer une Autorité de certification locale et signe Cert Demandes de clients, vous permettant de sauter le "faire venir dans le bureau" et la "charge de certificats sur le serveur' étapes.

La douleur du cou? Absolument. Bon pour tout? Nope. Très sécurisé? Yup.

Il repose sur les clients de garder leurs certificats sûr cependant (ils ne peuvent pas poster de leurs clés privées en ligne), et il est généralement utilisé lorsque vous vendez un service à la clientèle, plutôt que de laisser quelqu'un vous inscrire et de vous connecter.

De toute façon, il ne peut pas être la solution que vous cherchez pour (il n'est probablement pas pour être honnête), mais c'est une autre option.

18voto

pc1oad1etter Points 3910

HTTP Basic + HTTPS est une méthode courante.

9voto

dthorpe Points 23314

Si le choix entre OAuth versions, rendez-vous avec OAuth 2.0.

OAuth porteur de jetons doit être utilisé uniquement avec un transport en toute sécurité.

OAuth porteur jetons sont aussi sécurisés ou non sécurisés comme le transport qui permet de crypter la conversation. HTTPS prend soin de se protéger contre les attaques de relecture, de sorte qu'il n'est pas nécessaire pour le porteur du jeton à aussi une protection contre le rejeu.

S'il est vrai que si quelqu'un intercepte votre porteur du jeton ils peuvent se faire passer pour vous lors de l'appel de l'API, il y a beaucoup de façons d'atténuer ce risque. Si vous donnez à vos jetons une longue période d'expiration et s'attendre à vos clients de stocker les jetons localement, vous avez un plus grand risque de jetons être interceptées ou à mauvais escient, que si vous donnez à vos jetons une expiration courte, obliger les clients à acquérir de nouveaux jetons pour chaque session, et de conseiller les clients de ne pas persister jetons.

Si vous avez besoin pour sécuriser les charges qui passent par plusieurs participants, alors vous avez besoin de quelque chose de plus que HTTPS/SSL, depuis HTTPS/SSL uniquement crypte un lien du graphe. Ce n'est pas une faute de OAuth.

Porteur de jetons est facile pour les clients à obtenir, facile pour les clients à utiliser pour les appels d'API et sont largement utilisés (avec HTTPS) pour protéger le public face à des Api de Google, de Facebook, et de nombreux autres services.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: