Bei einem Authentifizierungstoken sendet der Client die Anmeldeinformationen, erhält ein Token und verwendet dieses bei allen folgenden Aufrufen. Der Server muss das Token speichern, um die Anforderungen zu validieren.
Bei zB PHP Sessions gibt der Server eine Session UID zurück, die der Client bei jeder Anfrage sendet. Der Server muss die Sitzung speichern.
In beiden Fällen muss der Server einen Zustand speichern, warum wird der erstere als zustandslos betrachtet?
Semantik. Eine Sitzung wird im Allgemeinen implementiert, indem jedem Benutzer eine eindeutige ID zugewiesen und diese ID in einem clientseitigen Cookie gespeichert wird. Das Authentifizierungs-Token wäre GENAU dasselbe - eine eindeutige Benutzer-ID irgendeiner Art. Cookies werden bei jeder Anfrage automatisch vom Browser zurückgesendet, und das Authentifizierungs-Token kann bei jeder Anfrage zurückgeschickt werden, sollte aber im Allgemeinen nur für die Anfragen gesendet werden, die tatsächlich eine Authentifizierung erfordern.
Der Unterschied hat damit zu tun, wie diese Token auf dem Server behandelt werden. Die Sitzungs-ID wird verwendet, um eine entsprechende Sitzung aus dem Speicher zu laden (z. B. eine Datei, ein DB-Datensatz, was auch immer), und diese Sitzungsdaten bleiben zwischen den Anforderungen bestehen.
Ein Authentifizierungs-Token hat keine zugehörige Sitzungsdatei. Es ist nur ein "Ich darf hier sein, und hier ist der Beweis".
Es gibt keinen Grund, warum eine Sitzungs-ID nicht zur Implementierung des Authentifizierungssystems verwendet werden kann. Selbst ein einfacher $_SESSION['logged_in'] = true würde die Sitzung in ein Authentifizierungssystem verwandeln.
Wenn erwartet wird, dass der Client immer ein Authentifizierungstoken für jede Anforderung sendet, muss der Server den Status nicht speichern. Es enthält alles, was es in der Nachricht benötigt, um zu bestimmen, wie die Anfrage ausgewertet wird.
Bestimmte Serverarchitekturen (ich denke speziell an Java-Servlets) werden benötigt, um ein Session-Cookie zurückzugeben, aber sie müssen es nicht verwenden, wenn es bei der nächsten Anfrage an sie zurückgegeben wird. In meiner Stateless-Servlet-Anwendung wird für jede Antwort ein anderes Cookie zurückgegeben, das die JSESSIONID darstellt. Also, in diesem Fall ist es nur Hintergrundgeräusche.
Die meisten Sitzungen sind aus zwei Gründen zustandsbehaftet:
Zunächst haben Sie in dieser Frage eine Sitzungsverwaltung und keine Tokenverwaltung beschrieben.
SessionIds werden vom Business-System selbst generiert. Der Arbeitsablauf ist der gleiche wie Ihre Frage.
Tokens werden normalerweise von einem unabhängigen System generiert und verwaltet, nicht von dem Business-System. Wenn der Client nachfolgende Aufrufe an den Geschäftsserver gesendet hat, nachdem er bereits ein Token erhalten hatte, musste der Geschäftsserver das Token vom Tokensystem überprüfen. Wenn wir also über das Geschäftssystem sprechen, sagen wir, es sei staatenlos.
Aus meiner Sicht ist Token nicht dazu da, um Authentifizierung zu handhaben, es ist dafür gedacht, wichtige Informationen sicher zu halten.
Referenz:
>Tags und Links php session authentication rest token