Naja.. das Thema ist halt ein Zweischneidiges Schwert.
Das REST (als Schnittstelle) Stateless ist heisst eigentlich auch, das ein Server, der über eine Stateless-Schnittstelle angesprochen wird, sich keine Informationen von woanders als vom Client holen darf, die gerade relevant sind.
Üblicherweise läuft Authentication nach dem Lehrbuch so ab:
Ein bestimmter REST-Service bekommt credentials (username, passwort) und erzeugt als Antwort ein
Access-Token. In diesem Token sind alle informationen zum User und seinen Rechten verschlüsselt.
Andere Services, die eine Authorisierung benötigen, erwarten als einen Parameter ein solches Token.
Jeder dieser Service-Calls überprüft dann, ob der Token (noch) valide ist, und liest die anderen benötigten Informationen aus.
Es braucht hierbei keine Session, da der Client alle Informationen (verschlüsselt und damit nicht manipulierbar) verwaltet.
Das wird aber genau zu dem Zeitpunkt unpraktikabel, wenn sich z.B. Berechtigungen im laufenden System ändern können, und eine solche Berechtigungsänderung vor dem Ablauf des Tokens auch berücksichtigt werden muss.
In diesem Falle würde man in der Praxis schon eine Auswertung der Rechte auf dem Server implementieren (anhand der UserId im Token), und hätte hiermit schon zumindest offiziell keine REST-Schnittstelle mehr. Dann ist aber auch der Schritt nicht weit, an einem Token im Hintergrund auch noch andere Session-Informationen fest zu machen, die der Service nutzen kann.
Will heissen, die Theorie von REST ist da sehr klar und eindeutig, in der Praxis wirst Du jedoch kaum echtes REST nach dem Lehrbuch finden.
Irgend einen Server state wird es doch häufiger geben, insbesondere in Zusammenhang mit Authorization. Der Trick ist dann dabei eigentlich nur, da so gut abzukaspeln, das man das dem Service von aussen nicht mehr ansieht, und es für die Nutzung des Services auch nicht wirklich relevant ist.