Nehmen wir an, ich schreibe einen Code, der einen HTTP-Aufruf an eine Web-API sendet, etwa wie folgt:
%Vor%Ich gebe diesen Code dann zwei Leuten, die in verschiedenen Städten leben und sie schlagen meine API von ihren jeweiligen Häusern (nur von irgendeinem Browser). Welche Informationen kann meine API von der http-Anfrage erhalten, die es mir erlaubt, die Person A und die Person B, die sie anruft, voneinander zu unterscheiden? Ist die IP immer verfügbar? Ist die MAC-Adresse jemals verfügbar? Was gibt es noch?
Wie kann Person A beim Aufruf meiner API so tun, als wäre sie Person B?
Was passiert außerdem, wenn Person C meine Web-API über ihre eigene Web-API (Backend) aufruft? Wird die gleiche Information verfügbar sein, oder was wird anders sein?
Dies ist eine allgemeine Frage. Wenn Sie jedoch spezifische Informationen erhalten möchten, nehmen wir an, dass ASP.NET Web API 2 die HTTP-Anforderungen empfängt.
Sie beschreiben den Wunsch nach Vorauthentifizierung.
Die IP wird immer verfügbar sein. Sie können den Dienst auf nur diese IP-Bereiche beschränken. Es ist keine gute Möglichkeit, eine Authentifizierung durchzuführen.
Der Versuch, herumzukommen und eine Authentifizierung durchführen zu müssen, ist nicht sicher. Sie sollten eine geeignete Authentifizierungsmethode verwenden. Die Kombination von IP-Einschränkungen mit anderen Methoden ist in Ordnung.
Die Antwort von John Meyer ist im Wesentlichen Pre-Shared-Token-basierte Benutzerauthentifizierung. Ein gültiges Token ist eine ständige Anmeldung. Das Token kann viel leichter kompromittiert werden als eine typische tokenbasierte Benutzerauthentifizierung, die ein temporäres Token mit einer begrenzten Lebensdauer erstellt.
Wenn Sie sich für die Pre-Shared-Token-Route entscheiden, verwenden Sie bitte eine Methode, die eine ordnungsgemäße Rotation oder Permutation des Tokens im Laufe der Zeit unterstützt, sodass es nicht anfällig für Replay-Angriffe ist.
Die beste Option für dieses Szenario ist die typische sessionstokenbasierte Benutzerauthentifizierung.
Wenn Sie tatsächlich nicht daran interessiert sind, wer Ihren Service nutzt, nur dass sie eindeutig identifiziert werden, können Sie sicher einen Session (oder permanenten oder beliebigen Lebenszeit) Cookie pro Benutzer einrichten http Set-Cookie header, die alle Clients automatisch respektieren und unterstützen sollten, und diese dann als Tracking-Methode verwenden.
Mein Team hat dies erreicht, indem gefordert wurde, dass bei allen Anfragen ein Identifikationsheader eingefügt wird. Dies erfordert einige Anpassungen seitens des Anrufers, erfordert aber nicht unbedingt, dass der Benutzer angemeldet ist. Natürlich könnte der Wert der Kopfzeile von böswilligen Benutzern geändert werden. Wenn diese Anrufe also sehr sicher sein müssen, werden Sie dies tun brauche traditionelle Authentifizierung.
Sie scheinen wirklich verwirrt darüber zu sein. Was Sie suchen, heißt Authentifizierung.
Wenn Sie C # getaggt haben, gehe ich davon aus, dass Sie Ihre API in C # entwickeln. Ich empfehle, Web Api
Es gibt heutzutage eine Reihe von Authentifizierungsmethoden. Wenn Sie eine Rest-API entwickeln, können Sie json web-Token verwenden.
Sie können viele Informationen über den Client erhalten, der Ihre API über Ссылка aufruft.
Ich denke, Sie können immer mit vollständig authentifiziert gehen. Ich sehe Ihren Wunsch, eine halb gesicherte Reihe von Endpunkten anzustreben, aber ich denke nicht, dass Ihnen dieser Ansatz am besten dienen würde. MAC, IP, User-Agent, benutzerdefinierte Felder alles kann gefälscht werden, um ehrlich zu sein. Mit einem Bearer-Token oder Session-Token zu gehen ist hier die einzige Wette. Für öffentliche Apis können Sie Benutzeranfragen basierend auf ip beschränken oder Sie können herausfinden, ob eine bestimmte IP versucht, Sie auszunutzen und sie somit zu blockieren, aber das Finden einer echten Identität ist sowieso nicht möglich.
Tags und Links javascript c# security http asp.net-web-api2