Je lis le PDF gratuit de Apigee à propos du design des API web. Si les autres PDF gratuits du site sont assez creux, celui là pose de bonnes questions qui font écho avec mes propres reflexions.
Je le prends dans le désordre et pour reprendre mes erreurs passées ou celles que j’ai vu chez les autres :
- Pas de système de session avec point d’entrée spécifique pour le login. Ça demande au client de se préoccuper de l’expiration de la session et de son maintient. Pour des appels isolés ça veut dire faire deux requêtes (login + action) au lieu d’une, avec un délai de réponse finale allongé et une charge plus importante pour le serveur. Sauf besoin spécifique, il faut rester en stateless : Chaque connexion contient ses propres informations d’authentification.
- Pas d’authentification par IP, comme je le vois trop souvent. Outre que c’est un potentiel problème de sécurité, c’est juste quelque chose de difficilement maintenable et c’est toujours au dernier moment quand on veut faire un correctif, une migration ou une bascule vers le serveur de secours en urgence qu’on se rend compte du problème.
- L’authentification HTTP Digest me semble être une mauvaise réponse à tous les problèmes. Pour améliorer légèrement la résistance aux interceptions, il faut stocker le mot de passe en clair côté serveur. Une authentification HTTP Basic avec du TLS pour sécuriser la communication me semble bien plus pertinent, et aussi plus simple à réaliser.
- Le système fait maison est toujours la pire solution, même si vous pensez savoir ce que vous faites. C’est un NO GO commun à toute problématique qui touche la sécurité. Vous avez plus de chances de vous tirer une balle dans le pied qu’autre chose, et pour le même prix ce sera toujours plus complexe quand vous communiquerez avec des tiers.
- OAuth 2 a la mauvaise idée d’être plus une boite à outils qu’une solution finie. Même les gros groupes se prennent les pieds dans le tapis avec ça. On rejoint un peu le système fait maison. OAuth a ses défauts, mais globalement est une sphère contrôlée que vous devriez préférer.
Au final il reste le choix entre l’authentification HTTP Basic, l’authentification par certificat client avec SSL/TLS, ou OAuth 1.0. Ma grille de choix est la suivante :
- OAuth s’il s’agit d’avoir une authentification à trois pattes. Hors de question d’imposer à l’utilisateur final de saisir ses mots de passes dans un logiciel tiers. Pour une API qui veut créer un écosystème de logiciels clients (type twitter) c’est le choix quasiment imposé. Oui il y a des difficultés pour le mobile ou pour ce qui n’est pas « navigateur », mais ces questions sont désormais largement documentées. Pensez bien que choisir ce type d’authentification demande un réel travail (par exemple trouver l’ergonomie pour permettre à l’utilisateur d’autoriser et retirer l’autorisation d’applications tierces sur votre propre système)
- HTTP Basic par défaut pour quasiment toutes les autres situations. C’est simple côté client, simple et maitrisé côté serveur, supporté partout et pour tout, suffisamment sécurisé si on passe par du SSL/TLS.
- Et les certificats clients avec SSL/TLS ? C’est une solution qui semble plus intéressante que l’authentification HTTP mais qui se révèle complexe pour pas mal d’interlocuteurs. La valeur ajoutée ne semble pas valoir la complexité supplémentaire si vous n’interagissez pas avec des entreprises de taille significative. J’y croyais beaucoup, mais finalement j’ai peu d’argument face à la simplicité du HTTP Basic.
Et vous ? vous utilisez quoi pour l’authentification de vos services ?
Laisser un commentaire