Bonjour,
Je poste après avoir visionné la vidéo de Grafikart sur les API REST.
Je dois créer une API REST pour une application web en utilisant le framework FuelPHP (super framework, au passage).
Aucun soucis dans tout ce qui est fonctionnement de l'API. Cependant, avant de me lancer concrètement dans la réalisation de l'API, je voudrais savoir exactement comment je dois sécuriser celle-ci.
Dans un premier temps, l'API sera privée, elle ne sera utilisée que par mon serveur, et non pas par différents utilisateurs.
Je me suis beaucoup documenté, voilà ce que j'en ai retenu :
La manière la plus fiable de sécuriser les requêtes d'une API est d'utiliser une signature unique pour chaque requête (comme c'est très bien expliqué dans ce lien) comme le fait Amazon Web Service.
Cependant, je me pose plusieurs questions :
-
Cela ne ralentit pas les temps de réponse des requêtes ? (car il faut à chaque fois calculer la signature côté client ET côté serveur)
-
Ai-je vraiment besoin de mettre cela en place alors que mon API ne sera pas ouverte aux utilisateurs/développeurs ?
Merci d'avance de votre aide
4 réponses
Salut, il s'agit en effet d'une manière fiable. Pour ton besoin, je partirai plutôt sur de la "basic HTTP authentication" : http://fr.wikipedia.org/wiki/Authentification_HTTP, qui est, à mon sens très suffisant pour ton besoin.
Kippt propose les deux par exemple : https://github.com/kippt/api-documentation/blob/master/authentication/authentication.md.
Regarde ce qu'ils mettent dans la section "Basic Auth" : "HTTP Basic Auth, you know the drill. Use your Kippt credentials to authenticate. Email is accepted as username as well. More information.
Note: Try to avoid using using this method as Token Auth is usually much safer. And never store user's password on a server."
Sinon il y a aussi la Digest Auth qui semble à priori un peu plus sûre. Cela permettrait de rester dans le fonctionnement HTTP. Je me demande juste si c'est complètement sécurisé par cette méthode, sachant que je sécuriserait les échanges par le biais d'un certificat SSL.
Le truc c'est que eux proposent une API externe, donc dans ce cas, en effet basic auth est un peu moins sécurisé.
En fait comme il dise, l'enregistrement d'une clé auth en base de donnée est moins sécurisé plutôt que de générer un token, mais cela dépend de certain facteur. Il faut savoir qu'il y a des grosses boites connu qui mettent à disposition des applications soit disant sécurisé, et j'ai beau ne pas être un expert en sécurité web, je me suis rendu compte qu'il y avait certaine boite de grande marque qui proposait des systèmes d'authentifications ou d'api qui étaient encore moins sécurisé que ce que tu viens d'écrire c'est te dire ! lol (exemple FiaNet j'ai refusé de bossé chez eux car ils avaient un code archaïque et sont soit disant spécialisé dans les traitements d'échanges sécurisé je tiens à préciser. ça fait peur).
Où tu choisis de créer un système effectivement basé sur Oauth2 en fait, où il faut créer un module qui générera un clé et un token, mais concrètement il n'y a pas forcément le besoin lorsque son application n'est pas reconnu, c'est valable je trouve pour des sites et application comme google, twitter, facebook etc... mais pour d'autres il faut entrevoir une autre façon de faire.
Tu peux tout à fait enregistrer la clé d'authentification en base de donnée, on dit que cela est moins sécurisé dans le cas où un hacker arrivait à avoir accès à la base de donnée, mais si tu cryptes la clé d'authentification avec un algorithme puissant (FuelPHP le fait très bien comme laravel avec les blowfish and co) + ton token personnel, ta clé d'authentification sera de toute manière crypté en base de donnée.
Après est ce que c'est plus lent dans les requêtes, non pas forcément, c'est plus rapide si tu préfères qu'une gestion d'ACL en terme de requête, car par exemple pour des acl à chaque page, requête ou action on doit vérifier tous les droits dans le cas d'une grosse application trouvant la justification de plusieurs acl différents.
Je m'étais aussi posé cette question au départ, mais c'est relativement rapide, puisque l'on effectue une seul requête de vérification à chaque fois.