Authentification API REST pour application web et application mobile
J'ai du mal à décider comment implémenter l'authentification pour une API RESTful qui sera sécurisée pour la consommation à la fois par une application web et une application mobile.
Tout d'abord, j'ai pensé étudier L'authentification de base HTTP sur HTTPS en option. Cela fonctionnerait bien pour une application mobile, où le nom d'utilisateur et le mot de passe pourraient être stockés dans le trousseau du système d'exploitation en toute sécurité et ne pourraient pas être interceptés en transit car la demande serait sur HTTPS. C'est aussi élégant pour L'API car ce sera complètement apatride. Le problème avec ceci est pour l'application web. Il n'y aura pas accès à un tel trousseau pour stocker le nom d'utilisateur et le mot de passe, donc je devrais utiliser un cookie ou localStorage, mais ensuite je stocke les détails privés de l'utilisateur dans un endroit facilement accessible.
Après plus de recherches, j'ai trouvé beaucoup de discussions sur l'authentification HMAC. Le problème que je vois avec cette approche est qu'il doit y avoir un secret partagé que seuls le client et le serveur connaissent. Comment puis-je obtenir ce par utilisateur secret pour un utilisateur particulier dans l'application web, sauf si j'ai un point de terminaison api/login qui prend le nom d'utilisateur / mot de passe et donne le secret à stocker dans un cookie? à utiliser dans les futures demandes. Ceci introduit l'État à L'API cependant.
Pour lancer une autre clé dans les travaux, j'aimerais pouvoir restreindre L'API à certaines applications (ou, pour pouvoir bloquer certaines applications d'utiliser L'API). Je ne vois pas comment cela serait possible avec l'application web étant complètement public.
Je ne veux pas vraiment implémenter OAuth. C'est probablement exagéré pour mes besoins.
Je me sens comme si Je ne comprenais pas complètement HMAC, donc je serais heureux d'avoir une explication et comment je pourrais l'implémenter en toute sécurité avec une application web et une application mobile.
Mettre à jour
J'ai fini par Utiliser HTTP Basic Auth, mais au lieu de fournir le nom d'utilisateur et le mot de passe réels à chaque requête, un point de terminaison a été implémenté pour échanger le nom d'utilisateur et le mot de passe contre une clé d'accès qui est alors fourni pour chaque demande authentifiée. Élimine le problème de stockage du nom d'utilisateur et du mot de passe dans le navigateur, mais bien sûr, vous pouvez toujours pêcher le jeton si vous aviez accès à la machine et l'utiliser. Avec le recul, j'aurais probablement regardé OAuth plus loin, mais c'est assez compliqué pour les débutants.
3 réponses
Vous devriez utiliser OAuth2. Voici comment:
1) L'Application Mobile
Les informations d'identification du client mobile app store que vous indiquez vous-même. Il utilise ensuite "attribution des informations D'Identification du mot de passe du propriétaire de la ressource" (voir http://tools.ietf.org/html/rfc6749#section-4.3 ) pour envoyer ces informations d'identification. À son tour, il obtient un jeton (porteur) qu'il peut utiliser dans les requêtes suivantes.
2) site web
Le site utilise " Authorization Code Grant "(voir http://tools.ietf.org/html/rfc6749#section-4.1):
Le site web voit la demande non autorisée et redirige le navigateur vers le point de terminaison d'autorisation activé par HTML dans L'api REST.
-
L'utilisateur s'authentifie avec le service REST
Le site REST redirige l'utilisateur vers le site Web avec un jeton d'accès dans L'URL.
Le site web appelle le site REST et échange le jeton d'accès en jeton d'autorisation.
Ici après que le site utilise le jeton d'autorisation pour accéder au service REST (au nom de l'utilisateur final)-généralement en incluant le jeton en tant que jeton "porteur" dans l'en - tête D'autorisation HTTP.
Ce n'est pas une science de fusée mais il faut du temps pour comprendre complètement.
3) restriction de l'accès à L'API pour certaines applications
Dans OAuth2, chaque client reçoit un ID client et un secret client (ici, "client" est votre application mobile ou votre site web). Le client doit envoyer ces informations d'identification lorsque autoriser. Votre service REST peut l'utiliser pour valider le client appelant
Une façon de résoudre le problème de l'authentification de l'utilisateur à L'API est de demander un jeton d'authentification à L'API lorsque l'utilisateur se connecte. Ce jeton peut ensuite être utilisé pour les requêtes suivantes. Vous avez déjà abordé cette approche-c'est assez sain.
En ce qui concerne la restriction de certaines applications web. Vous voudrez que chaque application web s'identifie à chaque requête et que cette authentification soit effectuée dans votre implémentation D'API. Assez simple et directe.
J'ai résolu cela pour ma propre API assez facilement et en toute sécurité sans avoir besoin d'exposer les informations d'identification du client.
J'ai également divisé le problème en 2 parties. Authentification API - est-ce une demande valide d'une entité reconnue (site web ou application native). L'autorisation D'API, est cette entité autorisée à utiliser ce point de terminaison particulier et le verbe HTTP.
L'autorisation est codée dans L'API à l'aide d'une liste de contrôle d'accès et des autorisations et paramètres utilisateur configurés dans le code de L'API, configuration et base de données au besoin. Une simple instruction if dans L'API peut tester l'autorisation et renvoyer la réponse appropriée (non autorisée ou les résultats du traitement de l'appel API).
L'authentification consiste maintenant à vérifier si l'appel est authentique. Pour ce faire, j'émet des certificats auto-signés aux clients. Un appel à L'API est effectué à partir de leur serveur quand ils le souhaitent-généralement lorsqu'ils génèrent leur première page (ou lorsqu'ils effectuent leur propre connexion à l'application vérifier). Cet appel utilise les certificats que j'ai fournis précédemment. Si de mon côté je suis heureux que le certificat soit valide, je peux renvoyer un nonce et une clé API générée limitée dans le temps. Cette clé est utilisée dans tous les appels ultérieurs à d'autres points de terminaison D'API, dans l'en-tête de Porteur par exemple, et elle peut être stockée assez ouvertement dans un champ de formulaire HTML ou une variable javascript ou une variable dans une application.
Le nonce empêchera les attaques de relecture et la clé API peut être volée si quelqu'un le veut - ils le feront ne pas pouvoir continuer à utiliser après son expiration ou si le nonce change avant de faire le prochain appel.
Chaque réponse de L'API contiendra le nonce suivant de si le nonce ne correspond pas, il retournera une erreur d'authentification. En fait, le nonce ne correspond pas, je tue aussi la clé API. Cela forcera alors un utilisateur D'API authentique à se réauthentifier à l'aide des certificats.
Tant que l'utilisateur final conserve ces certificats en toute sécurité et n'expose pas la méthode qu'il utilise pour appel d'authentification (comme en faire une requête ajax qui peut être rejouée) alors les API sont agréables et sécurisées.