REST Login HTTP Authentifizierung

heulendoch

Ensign
Registriert
Feb. 2014
Beiträge
252
Hallo zusammen,

gehen wir davon aus ich würde mich über ../api/login (GET) bei meinem REST Service einloggen. Die Logindaten würde ich dann im HTTP Header angeben, so wie hier definiert:
https://de.wikipedia.org/wiki/HTTP-Authentifizierung#Basic_Authentication

Bei dem Request auf ../api/login (GET) würde ich dann ein Token/Handle zurück liefern, das ich bei allen weiteren REST HTTP Requests für die Authentifizierung angebe und nicht mehr Benutzername + Passwort. Ist das so okay? Das Handle läuft nach einer gewissen Zeit, nachdem kein Request mehr kam, ab (oder natürlich durch ein explizites Logout).

Man sendet den Benutzernamen und Passwort also nur beim Login.

Beliebiger Request -> Prüfen ob Handle ok (letzte Aktion neuer als 30 Minuten oder so) [SQL Select] + Benutzer des Handles hat Zugriffsberechtigung auf die angefragte Info -> Zeitpunkt dieses Requests wird in Datenbank zum entsprechenden Handle geschrieben [SQL Update] -> angeforderte Infos werden ermittelt und zurück geliefert [SQL, Dateisystemstuff, ...]

Allerdings keine Ahnung wie viel Performance das kostet wenn zu jedem Request zusätzlich zu den eigentlichen SQL Abfragen noch die zwei für die "Sitzungsprüfung" dazu kommen, wenn man davon ausgeht, dass ~100+ Requests die Minute verabeitet werden sollen.

Grüße
 
Zuletzt bearbeitet:
Arbeite lieber stateless und lass den API Key bzw. die Login-Daten bei jedem Request mitgeben. Sich bei jeder Aktion vorher einzuloggen und/oder ggf. zu prüfen ob man eingeloggt ist, statt einfach den Key dem Request mitzugeben, ist Blödsinn. So muss server- sowie clientseitig immer ein Session-Handling implementiert werden, statt einfach den Key bzw. Credentials abzugleichen.

Bei dem Szenario wird es definitiv darauf hinaus laufen, dass für jede Art von Request zusätzlich ein Login-Request mitgesendet wird, weil man sich einfach nicht sicher sein kann, ob die Session immer noch gültig ist oder nicht. Und Session Handling ist absoluter Mist, wenn man stattdessen einfach einen API Key mitgeben könnte, der einen legitimiert, egal wann wo und wie.
 
  • Gefällt mir
Reaktionen: new Account()
so richtig weiß ich noch nicht, was du möchtest. Ich erkenne aus deinem Post 3 verschiedene Dinge: Basic Authentication, oAuth und (eigenes) Session Management.

Was genau möchtest du jetzt wissen?

Übrigens: 100 Requests pro Sekunde ist Spielkram wenn die Datenbank nicht Milliarden von Datensätzen beinhaltet und der SQL Query auch noch ziemlich Rechenaufwendig ist.
 
  • Gefällt mir
Reaktionen: psYcho-edgE
Man muss das Rad ja nicht neu erfinden... wie bereits erwähnt würde ich mal nach JWT schauen, falls NodeJs zum Einsatz kommt nach passportjs und dann haste ruck zuck ne lauffähige Anwendung zustande gebracht.
 
Die Server Anwendung wird in C# geschrieben werden. In was die Client Anwendung geschrieben wird ist aktuell unklar. Kommunziert werden soll aber über REST.

Die Benutzer haben ja nur ihr Login und ihr Passwort (Login über Maske), von einem API Key (im Prinzip soll der Handle/das Token das ja sein) wissen die nichts. Die kriegen für jedes ihrer Sitzungen einen Handle generiert, der dann für alle weiteren Requests der Sitzungen verwendet wird.
 
Wenn der Client ein Browser ist, kann der die Basic Authentication übernehmen. Die Client-Anwendung muss sich keine Anmeldedaten merken:
  • Client sendet ersten Request
  • Server antwortet mit: HTTP 401 Unauthorized
    • mit Header: "WWW-Authenticate" = "Basic realm=<app-name>"
  • der Browser fragt von sich aus Name und Passwort ab
    • wiederholt den ersten Request
    • mit Header: "Authorization" = "Base NAMEPASSBASE64ENCODED"
Alle weiteren Requests bekommen ab dann automatisch den Authorization-Header gesetzt. Bis der Browser irgendwann geschlossen wird. Wenn das zu unflexibel ist, kann auch die Client-Anwendung die Prozedur durchführen.
 
Aber so kann ich keine typische Login Maske definieren? Wenn man nicht eingeloggt ist, dann wird man ja normalerweise auf die Loginseite weitergeleitet. Ich möchte kein automatischen Login vornehmen, sondern wie auf jeder Homepage mich explizit einloggen müssen. Wie hier im Forum z. B.

Der Browser hat die ganze Zeit das Passwort und den Benutzernamen im Speicher (als Base64)?

Der Client kann sowohl ein Browser sein, aber auch eine C# Anwendung.

Meine Idee der Implementierung ist also dumm? Oder reden wir aneinander vorbei.
 
Ich verwende also JWT um von einer in einem DB gespeicherten Token weg zukommen, muss dann aber wieder eine DB haben in der nicht mehr funktionierende Tokens stehen sollen?
Have DB of no longer active tokens that still have some time to live

Verstehe ich einfach nicht weshalb es sinnvoll ist vom typischen Session Handling weg zukommen, wenn ich hier auch wieder eine Datenbank benötige und mir hier die Tokens merken muss (zwar nicht die aktiven, sondern die inaktiven).
 
Mach einfach JWT mit kurzer Lebensdauer (wenige Sekunden, Minuten, je nach Anwendungsszenario), welche von den Endpunkten der API, bei erfolgreicher Validierung des übergebenen JWT, zusammen mit der Antwort der API aktualisiert zurück gegeben werden. Dann brauchst du keine Datenbank mit abgelaufenen Token zu führen. Das implementiert man zusammen mit der Validierung des JWT als Middleware in die API rein.

Für die Erstanmeldung macht man typischerweise einen Authentifikations-Service, der Benutzername + Passwort per Basic-Auth akzeptiert oder alternativ eben ein separates, langlebiges JWT eventuell mit einer Hardware-ID oder so etwas als Payload, die natürlich auch abgeglichen wird (ID des anfragenden Browsers / Rechners mit der, die im JWT angeführt wird. Damit man das Token nicht einfach klauen und irgendwo anders verwenden kann), welches in einem persistenten Cookie / Speicher der Anwendung abgelegt und für den gewünschten Autologin (würde ich zwar nicht machen, so einen Autologin, aber wenns sein soll... kommt wohl auf den Anwendungszweck drauf an) verwendet wird. Der Auth-Service liefert dann als Antwort das erste kurzlebige JWT für die weitere Nutzung der Schnittstelle zurück.

Mag ein wenig wie hin- und her aussehen ist aber performant, sicher und wenn man drüber nachdenkt, auch gar nicht so verkehrt ;)
 
Zurück
Oben