BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Patterns d'authentification pour les API REST

Patterns d'authentification pour les API REST

«Tout le monde ressent le besoin d'écrire son propre protocole d'authentification», explique George Reese, selon lui l'une des choses qu'il a apprise en travaillaint sur une API pour les fournisseurs de cloud et les fournisseurs de SaaS. Dans un article, George propose un ensemble de normes pour tous les besoins d'authentification REST.

George, qui a mis au point plusieurs API de Web Services, observe que chacune nécessite un mécanisme d'authentification différent.

Je suis fatigué de perdre du temps à comprendre si le vendeur A vous oblige à signer votre requête avant ou après l'encodage des paramètres d'URL et j'en ai marre des fournisseurs qui insistent pour utiliser des informations d'identification sur l'utilisateur pour authentifier les appels d'API.

Il décrit les règles de conception des schémas d'authentification pour les API REST. "Soyons franc: si vous ne cryptez pas vos appels à l'API, vous ne faites même pas semblant d'être sécurisé".

1. Tous les appels à l'API REST doivent avoir lieu via HTTPS avec un certificat signé par une CA de confiance. Tous les clients doivent valider le certificat avant de pouvoir interagir avec le serveur.

Grâce à l'utilisation de certificats signés par une autorité de confiance, SSL vous protège également contre les attaques de type «man-in-the-middle» dans lequel un agent s'insère entre le client et le serveur et renifle le trafic crypté.

Si vous ne validez pas le certificat SSL du serveur, vous ne savez pas qui reçoit vos requêtes REST.

2. Tous les appels REST devraient avoir lieu grâce aux clés d'API dédiées, constituées d'une composante partagée, et d'une autre privée. Les systèmes doivent permettre à un client donné d'avoir plusieurs clés d'API actives et désactiver ces clés individuellement et facilement.

La première chose importante est que le système qui fait la requête REST n'est pas un utilisateur interactif. [...] REST authentifie un programme et non pas la personne, il permet une authentification plus forte que le permet le pattern clasique "Utilisateur ID/Mot de passe"

La deuxième partie explique que chaque serveur REST devrait supporter des clés d'API multiples pour chaque client. Cette exigence permet plus facilement d'isoler des conflits potentiels et de les traiter lorsqu'ils surviennent. [...] Quand une application est compromise, vous devez disposer aussi d'une façon élégante pour redéployer de nouvelles clés

3. Toutes les requêtes REST doivent être authentifiées en signant les paramètres de requête, triés en minuscules, par ordre alphabétique, en utilisant les informations d'identification en tant que token de signature. La signature doit avoir lieu avant l'encodage des paramètres de l'URL.

En d'autres termes, vous ne passez pas la clé partagée dans la requête, mais vous l'utilisez pour signer la requête. Vos requêtes finissent par ressembler à ceci:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

La chaîne signée étant "/object?apikey=Qwerty2010&timestamp=1261496500" et la signature est le hachage HMAC-SHA256 de cette chaîne en utilisant la partie privée de la clé de l'API.

Il admet que dans la plupart des API RESTlike et RESTFul, l'authentification est très certainement une considération secondaire. Cependant, dans la conclusion de son article, il exhorte les lecteurs à "prendre l'exemple de quelqu'un d'autre et non refaire son propre système d'authentification".

Le message original peut être trouvé sur les blogs de la communauté O'Rielly.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT