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 Schlüsselpunkt, 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 so sollte es 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 die Forderung, und die Sammlung von Forderungen könnte als Container verwendet werden

• cookies (wie oben besprochen)
• 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-basedoder Token-Claims-basedAuthentifizierungen, wenn sie über Authentifizierungstypen sprechen?

Ich stimme zu, dass die Benennung der verschiedenen Konzepte verwirrend ist. Wenn von Authentifizierung in einem Webkontext die Rede ist, sind mehrere Aspekte zu 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 serverseitig statusbehaftet .
• Eine Reihe von Ansprüchen . Ansprüche enthalten Informationen darüber, welche Vorgänge der Kunde ausführen kann. Der Server verfolgt nicht jeden authentifizierten Client, vertraut jedoch den Ansprüchen. Ansprüche sind normalerweise auf der Serverseite zustandslos .

Wie sendet der Client die Authentifizierungsinformationen?

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

Was ist das Format der Authentifizierungsinformationen?

• Einfacher, nicht signierter Text . Dies kann für Sitzungs-IDs verwendet werden. Eine Sitzungs-ID kann der Client im Allgemeinen nicht erraten, 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 entschlüsseln, aber nicht ändern, ohne dass der Server dies bemerkt.
• Jedes andere signierte Format . Gleich wie JWTs. Wichtig ist die kryptografische Signatur, die verhindert, dass der Client die Daten ändert.

Bonus: Wie speichert der Kunde die Informationen lokal?

• Kekse . Dies ist natürlich der Fall, wenn zur Übermittlung der Informationen Cookies verwendet werden. Cookies können jedoch auch nur als clientseitiger Speichermechanismus verwendet werden. Dies setzt voraus, dass das Cookie in Skripten lesbar ist, um nützlich zu sein. Beispielsweise könnte ein Kunde das Cookie mit JavaScript lesen und die Informationen mit einem Authorization-Header versenden.
• Lokale Speicherung . Dies ist häufig die einzig mögliche Methode, wenn Cookies nicht verfügbar sind. Erfordert die Verwaltung mit JavaScript.

Was meinen die Leute, wenn sie sagen ...

• "Cookie-basierte Authentifizierung" . Ich stelle fest, dass dies normalerweise "Sitzungs-ID, per Cookie gesendet, als Klartext möglich" bedeutet.
• Msgstr "Token - basierte Authentifizierung" . In der Regel bedeutet dies "Ansprüche, die unter Verwendung des als Json-Web-Token codierten Authentifizierungs-Headers gesendet werden".
• "Anspruchsbasierte Authentifizierung" . Könnte alles andere als eine Sitzungs-ID sein.

Einfach gesagt,

1. Cookie-basierte Authentifizierung

   • Der Web-Client (zB: Web-Browser) speichert Cookies, die nach erfolgreicher Authentifizierung vom Web-Server gesendet werden.
   • Das Cookie enthält Informationen über den Benutzer, den Client, den AuthN-Zeitstempel und andere nützliche Daten mit einer eindeutigen ID zur Bestimmung des Cookies.
   • In der Regel wird ein Cookie vom Web-Server mit einem festgelegten Domain-Attribut (z. B.:) verschlüsselt google.comund an den Web-Client gesendet .
   • Wann immer der Web-Client auf die Domain-Ressource zugreifen möchte (zB mail.google.com:), sendet er alle Cookies basierend auf seiner Domain (zB:) google.coman den Web-Server, der den Zugriff basierend auf Status und Zeitstempel von validiert / verifiziert und gewährt / verweigert der Keks.

2. Sitzungsbasierte Authentifizierung

   • Wenn ein Webserver zusammen mit dem Web-Client-Cookie die Authentifizierungsdaten des Benutzers in seinem Back-End speichert, wird dies als sitzungsbasierte Authentifizierung bezeichnet.
   • Dies ist sehr nützlich für den Fall, dass der Web-Client Zugriff auf das System hat, auf das er keinen Zugriff erhalten soll. Anschließend kann die Sitzung des Web-Clients über das Back-End 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, Authentifizierungszeitstempel und andere nützliche 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 das Token, bevor er auf die Ressource zugreifen kann.

4. Anspruchsbasierte Authentifizierung

   • Dies ist mit der tokenbasierten Authentifizierung identisch, nur dass dem Token weitere Daten zu dem Client und / oder dem dem Client zugeordneten Benutzer hinzugefügt werden.
   • Diese Daten beziehen sich auf die Autorisierung, die darüber spricht, was der Kunde innerhalb der Ressource tun soll (z. B. mail.read, mail.delete, calendar.read).