it-swarm.com.de

Cookie-basierte vs Session vs Token-basierte vs Claims-basierte Authentifizierung

Ich habe über Authentifizierungen gelesen und bin verwirrt über die Klassifizierung von Typen.

Beginnen wir mit der Cookie-basierten Authentifizierung. Wenn ich es richtig verstehe, ist der entscheidende Punkt, dass alle Daten, die für die Benutzerauthentifizierung benötigt werden, in Cookies gespeichert werden. Und das ist meine erste Verwirrung: In Cookies können wir speichern

  • sitzungs-ID und so wird es eine sitzungsbasierte Authentifizierung?
  • ansprüche, und sollte es daher als anspruchsbasierte Authentifizierung bezeichnet werden?
  • Ich habe festgestellt, dass einige Leute sogar JWT-Token in Cookies speichern, aber dies scheint eine benutzerdefinierte Implementierung des eigenen Authentifizierungsflusses zu sein ...

Wechseln wir nun zur anspruchsbasierten Authentifizierung. Das Hauptelement ist der Anspruch, und die Sammlung von Ansprüchen könnte als Container verwendet werden

  • cookies (wie oben beschrieben)
  • token (JWT als Beispiel).

Von der anderen Seite, wenn wir über das Token sprechen, kann es jede Art von Information enthalten ... Sitzungs-ID zum Beispiel ...

Was habe ich vermisst? Warum definieren die Leute nicht so etwas wie Cookie-Session-based oder Token-Claims-based Authentifizierungen bei Authentifizierungstypen?

26
Set

Ich stimme zu, dass die Benennung der verschiedenen Konzepte verwirrend ist. Wenn Sie über die Authentifizierung in einem Webkontext sprechen, müssen Sie verschiedene Aspekte berücksichtigen.

Welche Informationen sendet der Client bei der Authentifizierung?

  • Eine Sitzungs-ID. Dies bedeutet, dass der Server über einen Sitzungsspeicher verfügt, der die aktiven Sitzungen enthält. Sitzungen sind auf der Serverseite statusbehaftet .
  • Eine Reihe von Ansprüchen. Ansprüche enthalten Informationen darüber, welche Vorgänge der Kunde ausführen darf. Der Server verfolgt nicht jeden authentifizierten Client, sondern vertraut den Ansprüchen. Ansprüche sind auf der Serverseite normalerweise zustandslos .

Wie sendet der Client die Authentifizierungsinformationen?

  • Cookies. Browser senden Cookies automatisch bei jeder Anfrage, nachdem das Cookie gesetzt wurde. Cookies sind anfällig für XSRF.
  • Andere Header. In der Regel wird hierfür der Authorization-Header verwendet. Diese Header werden nicht automatisch vom Browser gesendet, sondern müssen vom Client festgelegt werden. Dies ist anfällig für XSS.
  • RL anfordern. Die Authentifizierungsinformationen sind in der URL enthalten. Dies wird nicht häufig verwendet.

Wie ist das Format der Authentifizierungsinformationen?

  • Einfacher, nicht signierter Text. Dies kann für Sitzungs-IDs verwendet werden. Eine Sitzungs-ID kann vom Client im Allgemeinen nicht erraten werden, sodass der Server darauf vertrauen kann, dass der Client sie nicht gefälscht hat.
  • Json Web Token. JWTs sind kryptografisch signiert und enthalten Ablaufinformationen. Der Client kann das Token normalerweise dekodieren, aber nicht ändern, ohne dass der Server dies bemerkt.
  • Jedes andere signierte Format. Gleich wie JWTs. Wichtig ist die kryptografische Signatur, die den Client daran hindert, die Daten zu ändern.

Bonus: Wie speichert der Kunde die Informationen lokal?

  • Cookies. Dies ist natürlich der Fall, wenn Cookies zur Übertragung der Informationen verwendet werden. Cookies können aber auch nur als clientseitiger Speichermechanismus verwendet werden. Dies setzt voraus, dass das Cookie aus Skripten lesbar ist, um nützlich zu sein. Beispielsweise könnte ein Client das Cookie mit JavaScript lesen und die Informationen mit einem Authorization-Header senden.
  • lokaler Speicher. Dies ist oft die einzig mögliche Methode, wenn keine Cookies verfügbar sind. Erfordert die Verwaltung mit JavaScript.

Was meinen die Leute, wenn sie sagen ...

  • "Cookie-basierte Authentifizierung". Ich finde, dass dies normalerweise "Sitzungs-ID, per Cookie senden, möglich als einfacher Text" bedeutet.
  • "Token-basierte Authentifizierung". Normalerweise bedeutet dies "Ansprüche, die mithilfe des Authentifizierungs-Headers gesendet werden und als Json-Web-Token codiert sind."
  • "Anspruchsbasierte Authentifizierung". Könnte alles andere als eine Sitzungs-ID sein.
38
TheFogger

Einfach gesagt,

  1. Cookie-basierte Authentifizierung

    • Der Web-Client (z. B. Webbrowser) speichert Cookies, die vom Webserver nach erfolgreicher Authentifizierung gesendet wurden.
    • Das Cookie enthält Informationen über den Benutzer, den Client, den AuthN-Zeitstempel und andere nützliche Daten mit einer eindeutigen ID, um das Cookie zu ermitteln.
    • In der Regel wird das Cookie vom Webserver mit festgelegten Domänenattributen verschlüsselt (z. B.: google.com) und senden Sie es an den Web-Client.
    • Wann immer der Webclient auf die Domänenressource zugreifen möchte (z. B.: mail.google.com) sendet es alle Cookies basierend auf seiner Domain (zB: google.com) an den Webserver, der den Zugriff basierend auf dem Status und dem Zeitstempel des Cookies überprüft/überprüft und gewährt/verweigert.
  2. sitzungsbasierte Authentifizierung

    • Wenn ein Webserver zusammen mit dem Webclient-Cookie die Benutzerauthentifizierungsdaten in seinem Back-End speichert, wird dies als sitzungsbasierte Authentifizierung bezeichnet.
    • Dies ist sehr nützlich im Falle eines Verstoßes, bei dem der Webclient Zugriff auf das System erhalten hat, auf das er keinen Zugriff erhalten sollte. Anschließend kann die Sitzung des Webclients vom Back-End aus vom Administrator widerrufen werden.
  3. Token-basierte Authentifizierung

    • Im Allgemeinen wird dies in Nicht-Web-Client-Szenarien verwendet, in denen es keine Möglichkeit gibt, Cookies auf der Client-Seite zu speichern.
    • Daher sendet der Webserver das signierte Token (enthält Informationen zu Benutzer, Client, AuthN-Zeitstempel und anderen nützlichen Daten mit eindeutiger ID) nach erfolgreicher Authentifizierung an den Client.
    • Wenn ein Client auf eine Ressource zugreifen möchte, muss er dieses Token senden, und der Webserver überprüft/überprüft das Token, bevor er auf die Ressource zugreifen kann.
  4. Anspruchsbasierte Authentifizierung

    • Dies entspricht der tokenbasierten Authentifizierung, nur dass dem Token weitere Daten zum Client und/oder Benutzer hinzugefügt werden, die dem Client zugeordnet sind.
    • Diese Daten beziehen sich auf die Autorisierung, die darüber spricht, was der Client innerhalb der Ressource tun soll (z. B. mail.read, mail.delete, calendar.read).
3
Zeigeist