Disons que j'écris un morceau de code qui rend un appel http à une API Web, quelque chose comme:
$http.get('www.myapi.com/api/controller/endpoint').then(function(resp){...})
4 Réponses :
Mon équipe a accompli ceci en exigeant qu'un en-tête d'identification soit inclus sur toutes les demandes. Cela nécessite une certaine personnalisation de la part de la partie appelante, mais n'exige pas nécessairement que l'utilisateur soit connecté. Bien entendu, la valeur de l'en-tête pourrait être modifiée par des utilisateurs malveillants afin que ces appels doivent être très sécurisés, vous devez être très sécurisé. besoin d'une authentification traditionnelle.
Vous décrivez un désir de pré-authentification.
L'IP sera toujours disponible. Vous pouvez limiter le service à seulement ces gammes IP. Ce n'est pas un bon moyen de faire de l'authentification.
Essayer d'avoir à effectuer une authentification n'est pas sûr. Vous devez utiliser une méthode d'authentification appropriée. La combinaison des restrictions IP avec d'autres méthodes est bonne.
La réponse de John Meyer est essentiellement authentification de l'utilisateur basée sur jeton pré-partagé. Avoir un jeton valide constitue être constamment connecté. Le jeton peut être compromis beaucoup plus facilement qu'une authentification typique basée sur votre jeton qui établit un jeton temporaire avec une durée de vie limitée.
Si vous décidez de suivre la route de jeton pré-partagée, veuillez utiliser une méthode qui prend en charge la rotation correcte ou la permutation du jeton au fil du temps, de sorte qu'il n'est pas vulnérable aux attaques de replay.
Votre meilleure option pour ce scénario est une authentification de l'utilisateur basée sur jeton de session typique.
Si vous êtes en fait pas intéressé par qui utilise votre service, seulement qu'ils sont identifiés de manière unique, vous pouvez établir une session en toute sécurité une session (ou une durée de vie permanente ou arbitraire) par utilisateur par le http set-cookie en-tête que tous les clients doivent automatiquement respecter et prendre en charge, puis utiliser cela comme méthode de suivi.
Je pense que vous pouvez toujours aller avec entièrement authentifié. Je vois votre désir d'aller pour un ensemble de critères semi-sécurisés, mais je ne pense pas que l'approche ne vous servirait mieux. Mac, IP, utilisateur utilisateur, champs personnalisés, tout peut être utilisé pour être honnête. Aller avec un jeton au porteur ou un jeton de session est votre seul pari ici. Pour les API publiques, vous pouvez limiter les demandes d'utilisateurs en fonction de la propriété intellectuelle ou vous pouvez essayer de déterminer si une adresse IP spécifique tente de vous exploiter et donc de le bloquer, mais la recherche d'une véritable identité pourrait ne pas être possible de toute façon.
Vous semblez vraiment confus à ce sujet. Ce que vous cherchez s'appelle l'authentification.
Comme vous avez marqué C #, je suppose que vous développez votre API en C #. Je recommande de vérifier API Web .
Il y a quelques méthodes d'authentification disponibles ces jours-ci. Si vous développez une API de repos, vous pouvez utiliser jetons Web JSON .
Vous pouvez obtenir de nombreuses informations sur le client appelant votre API via HTTP HTTP .
Peut-être créer deux curseurs en utilisant un à l'intérieur de l'autre?
Qu'essayez-vous d'accomplir cette information?
@MRMCGGG: Les points d'extrémité sécurisés qui ne nécessitent pas que l'utilisateur soit connecté. Ou au moins, donnez-nous un moyen d'identifier et de verrouiller les utilisateurs malveillants. Pour l'instant, j'essaie juste d'obtenir une image globale cependant.
Vous aurez beaucoup de ces choses, mais ils pourraient être plus ou moins utiles à vos besoins. Les MAC sont facilement spoofés et les clients partageant un routeur auront tous la même adresse IP.
Vous aurez également la plupart des mêmes choses, à l'exception de certaines des trucs de navigateur, lorsque quelqu'un fait un appel d'API d'un backend.