Comment sécuriser les services web RESTful?

Question

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

Options :

TLS (HTTPS) +

• HTTP Basic (pc1oad1etter)
• HTTP Digest
• deux-tiers OAuth
• une approche basée sur les cookies
• certificats clients (Tom Ritter et ici)
• Requêtes signées en utilisant HMAC et une durée de vie limitée

Y a-t-il d'autres options possibles à considérer ? Si OAuth, quelle version ? Est-ce que cela importe même ? D'après ce que j'ai lu jusqu'à présent, OAuth 2.0 avec des jetons d'accès (c'est-à-dire sans signatures) semble être peu sécurisé.

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

Sécurisez votre API REST... Le bon chemin

Answer 1

Il existe une autre méthode très sécurisée. Il s'agit des certificats client. Savez-vous comment les serveurs présentent un certificat SSL lorsque vous les contactez en https? Eh bien, les serveurs peuvent demander un certificat à un client afin de vérifier que le client est bien qui il prétend être. Les clients génèrent des certificats et vous les remettent via un canal sécurisé (comme en venant dans votre bureau avec une clé USB - de préférence une clé USB non infectée).

Vous chargez les certificats client (et éventuellement les certificats de leurs signataires) dans votre serveur web, et le serveur web n'acceptera plus de connexions de personne sauf les personnes qui possèdent les clés privées correspondantes aux certificats qu'il reconnaît. Cela fonctionne au niveau de la couche HTTPS, ce qui vous permet même de vous passer complètement de l'authentification au niveau de l'application comme OAuth (selon vos besoins). Vous pouvez ajouter une couche d'abstraction en créant une autorité de certification locale et en signant les demandes de certificats des clients, ce qui vous permet de vous passer des étapes "faire venir les clients au bureau" et "charger les certificats sur le serveur".

Est-ce contraignant? Absolument. Convient-il à tout? Non. Très sécurisé? Oui.

Toutefois, cela suppose que les clients gardent leurs certificats en sécurité (ils ne doivent pas divulguer leurs clés privées en ligne) et est généralement utilisé lorsque vous vendez un service à des clients plutôt que de permettre à n'importe qui de s'inscrire et de se connecter.

Quoi qu'il en soit, cela pourrait ne pas être 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 les versions d'OAuth, optez pour OAuth 2.0.

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

Les jetons d'accès OAuth sont aussi sécurisés ou insécurisés que le transport qui chiffre la conversation. HTTPS prend en charge la protection contre les attaques de rejeu, il n'est donc pas nécessaire que le jeton d'accès protège également contre le rejeu.

Il est vrai que si quelqu'un intercepte votre jeton d'accès, il peut se faire passer pour vous lors de l'appel à l'API, mais 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 attendez de vos clients qu'ils stockent les jetons localement, vous courez un plus grand risque que les jetons soient interceptés et utilisés de façon abusive 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 devez sécuriser les charges utiles qui passent par plusieurs participants, vous avez besoin de quelque chose de plus qu'HTTPS/SSL, car HTTPS/SSL ne chiffre qu'un lien du graphe. Ce n'est pas un défaut d'OAuth.

Les jetons d'accès 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.