8
votes

Recommandation de l'authentification de l'API reposante?

Je développe plusieurs API reposant pour la tierce partie à appeler, et ces API ont besoin d'une authentification (Apikey & Secret Base) et d'autorisation (méthode HTTP et basée sur URI).

Y a-t-il des logiciels existants que nous pouvons réutiliser qui m'empêche de déployer notre propre implémentation pour la couche de sécurité?

api rest restful-authentication

0 commentaires

3 Réponses :

7
votes

http vous donne un support accordé pour cela, de sorte que vous n'avez pas besoin de réinventer la roue

Utiliser:

HTTP Auth Basic (avec SSL pour contourner le problème du mot de passe de texte plain-texte)
http auth digest
Auth Digest a un avantage, qu'il ne transmet pas le Passowrd en clairtext et gère les attaques de replay (avec des non -ances).
Nous utilisons HTTP Auth Digest (le conteneur de servlet Tomcat a un support direct pour cela) et nous sont contenus avec elle.
Edit: Certains clients ont des problèmes avec Digest (pas si trivial), donc ces jours-ci, je choisirais pour la base et le SSL. Avantage pour la base est également que vous pouvez votre authentification préventive (utilisateur d'envoi: PWD dans la première demande).

2 commentaires

Je veux aussi une autorisation, par ex. Quelques API telles que POST Exemple.com/Ajouter , j'accorde uniquement l'accès à un client.

Je vois, cela dépend alors de votre plate-forme technologique que vous utilisez. Si vous utilisez Java et Servlet-Contener, vous pouvez utiliser une autorisation intégrée basée sur des rôles. Vous attachez ces rôles aux URL autorisées et peuvent donc être des visibilités. Vous regroupez ensuite un ensemble de clients aux rôles (c'est-à-dire client1 + 2 appartenant à Rôle1, client3-6 au rôle2). Si l'approche de base de rôle est trop grossière (c'est-à-dire que chaque client a différentes règles d'accès), vous devez mettre en œuvre une autre couche d'autorisation. Mais d'abord, essayez de déterminer si la sécurité des rôles correspond à vos besoins (plus facile à mettre en œuvre).

2
votes

Si vous construisez votre API en utilisant Ruby sur des rails (3.2.0 ou supérieur), consultez la gemme réelle_api_authentication - https://rubygems.org/gems/resful_api_authentication

0 commentaires

0
votes

indépendamment de votre technologie, vous pouvez implémenter un système comme des utilisations AWS.

Chaque enregistré utilisé doit avoir un ID utilisateur et une clé d'accès secrète.
Chaque demande doit être signée avec le SAK et doit contenir l'ID utilisateur. (Prenez en compte The Time Time).
Le serveur, étant donné l'ID utilisateur, récupère à partir de DB le SAK et signe à nouveau la demande, si la signature continue, sinon, renvoyez une erreur.
La mise en œuvre n'est pas trop difficile, mais vous devez prendre en compte chaque demande de serveur nécessite d'interroger le magasin pour récupérer le SAA. Une option consiste à utiliser un dB NOSQL ou similaire (comme Redis ou Memcache) pour stocker l'ID utilisateur / Sak.

0 commentaires