Comment sécuriser les services Web RESTful?

Je dois implémenter des services Web sécurisés RESTful . J'ai déjà fait des recherches avec Google mais je suis bloqué.

Options:

TLS (HTTPS) +

• HTTP de base (pc1oad1etter)
• Résumé HTTP
• OAuth à deux pattes
• une approche basée sur les cookies
• certificats clients (Tom Ritter et ici )
• Requêtes signées utilisant HMAC et durée de vie limitée

Y a-t-il d'autres options possibles à considérer? Si OAuth alors quelle version? Cela a-t-il même une importance? D'après ce que j'ai lu jusqu'à présent, OAuth 2.0 avec des jetons de support (c'est-à-dire sans signatures) semble ne pas être sécurisé .

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

Sécurisez votre API REST ... de la bonne manière

Il existe une autre méthode très sûre. Ce sont des certificats clients. Vous savez comment les serveurs présentent un certificat SSL lorsque vous les contactez sur https? Eh bien, les serveurs peuvent demander un certificat à un client afin qu'ils sachent que le client est qui ils prétendent être. Les clients génèrent des certificats et vous les remettent via un canal sécurisé (comme entrer dans votre bureau avec une clé USB - de préférence une clé USB sans cheval de Troie).

Vous chargez la clé publique des certificats clients cert (et le (s) certificat (s) de leur signataire, si nécessaire) dans votre serveur Web, et le serveur Web n'acceptera les connexions de personne, sauf les personnes qui ont les clés privées correspondantes pour les certificats il sait. Il fonctionne sur la couche HTTPS, vous pouvez donc même ignorer complètement l'authentification au niveau de l'application comme OAuth (en fonction de vos besoins). Vous pouvez extraire une couche et créer une autorité de certification locale et signer les demandes de certificat des clients, ce qui vous permet d'ignorer les étapes «les faire entrer au bureau» et «charger les certificats sur le serveur».

Douleur au cou? Absolument. Bon pour tout? Nan. Très sécurisé? Ouaip.

Cependant, il repose sur la sécurité des certificats par les clients (ils ne peuvent pas publier leurs clés privées en ligne), et il est généralement utilisé lorsque vous vendez un service à des clients plutôt que de laisser quiconque s'inscrire et se connecter.

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

HTTP Basic + HTTPS est une méthode courante.

Si vous choisissez entre les versions OAuth, optez pour OAuth 2.0.

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

Les jetons de support OAuth ne sont aussi sécurisés ou non sécurisés que le transport qui crypte la conversation. HTTPS prend en charge la protection contre les attaques de relecture, il n'est donc pas nécessaire que le jeton porteur se prémunisse également contre la relecture.

S'il est vrai que si quelqu'un intercepte votre jeton porteur, il peut se faire passer pour vous lors de l'appel de l'API, il existe de nombreuses façons d'atténuer ce risque. Si vous donnez à vos jetons une longue période d'expiration et que vous vous attendez à ce que vos clients stockent les jetons localement, vous courez un plus grand risque que les jetons soient interceptés et mal utilisés que si vous donnez à vos jetons une courte expiration, exigez que les clients acquièrent de nouveaux jetons pour chaque session, et conseillez aux clients de ne pas conserver les jetons.

Si vous avez besoin de sécuriser des charges utiles qui passent par plusieurs participants, vous avez besoin de quelque chose de plus que HTTPS / SSL, car HTTPS / SSL crypte uniquement un lien du graphique. Ce n'est pas une faute d'OAuth.

Les jetons de support 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.