Comment sécuriser les services Web RESTful?
Je dois implémenter des services Web RESTful sécurisés . J'ai déjà fait des recherches en utilisant Google mais je suis coincé.
Options:
TLS (HTTPS) +
- HTTP de Base (pc1oad1etter)
- Résumé HTTP
- deux pattes OAuth
- une approche basée sur les cookies
- certificats clients (Tom Ritter et ici )
- Demandes signées utilisant HMAC et une limite durée de vie
Y a-t-il plus d'options possibles à considérer? Si OAuth alors quelle version? Est-il encore de l'importance? D'après ce que j'ai lu jusqu'à présent OAuth 2.0 avec des jetons au porteur (c'est-à-dire sans signatures) semble être insecure .
J'ai trouvé un autre article très intéressant sur Authentification basée sur le REPOS.
3 answers
Il existe une autre méthode très sécurisée. Ce sont des certificats clients. Savoir comment les serveurs présentent un certificat SSL lorsque vous les contactez sur https? Les serveurs de puits peuvent demander un certificat à un client afin qu'ils sachent que le client est qui ils disent qu'ils sont. Les clients génèrent des certificats et vous les donnent via un canal sécurisé (comme entrer dans votre bureau avec une clé USB - de préférence une clé USB non-troyaned).
Vous chargez la clé publique des certificats clients cert (et de leur signataire certificat(s), 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 qu'il connaît. Il s'exécute 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 abstraire une couche et créer une autorité de certification locale et signer les demandes de certificat des clients, vous permettant d'ignorer le " make ils entrent dans le bureau " et "charger des certificats sur le serveur" étapes.
Douleur au cou? Absolument. Bon pour tout? Nope. Très sécurisé? Yup.
Il s'appuie cependant sur les clients qui 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 quiconque s'inscrire et se connecter.
De toute façon, ce n'est peut-être pas la solution que vous recherchez( ce n'est probablement pas pour être honnête), mais c'en 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 porteurs OAuth ne doivent être utilisés qu'avec un transport sécurisé.
Les jetons porteurs OAuth sont aussi sécurisés ou non sécurisés que le transport qui crypte la conversation. HTTPS prend soin de se protéger contre les attaques de relecture, il n'est donc pas nécessaire que le jeton porteur se prémunisse également contre la relecture.
Bien qu'il soit 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 d'interception et d'utilisation abusive des jetons que si vous donnez à vos jetons une courte expiration, exigez que les clients acquièrent de nouveaux jetons pour chaque session et conseillez aux
Si vous avez besoin de sécuriser les charges utiles qui passent par plusieurs participants, vous avez besoin de quelque chose de plus que HTTPS / SSL, car HTTPS / SSL ne crypte qu'un seul lien du graphique. Ce n'est pas une faute 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.