Session-Authentication ist ein Authentifizierungsverfahren, bei dem sich ein Client einmalig mit Benutzername und Passwort am Server anmeldet und im Gegenzug eine zeitlich begrenzte Sitzungskennung erhält — typischerweise als Cookie. Alle folgenden Anfragen übergeben diese Kennung statt der eigentlichen Zugangsdaten; der Server löst die Kennung serverseitig auf und kennt damit den zugehörigen Benutzer.
Kontext
Der Service Layer von SAP Business One arbeitet konsequent mit Session-Authentication. Der Login-Aufruf POST /b1s/v2/Login mit JSON-Payload {CompanyDB, UserName, Password} setzt bei Erfolg ein B1SESSION-Cookie; dieses wird in allen weiteren HTTP-Requests mitgeschickt. Sessions laufen nach einer konfigurierten Leerlaufzeit ab und liefern dann HTTP-401-Antworten — Clients müssen deshalb eine Auto-Relogin-Logik implementieren, die 401 abfängt, neu anmeldet und die Ursprungsanfrage wiederholt. Vorteile sind einfache Integration (nur Cookie-Management nötig, keine Token-Handhabung), klare Zuordnung auf einen B1-Company-Mandanten und serverseitige Widerrufbarkeit per Logout. Der DI-Server nutzt eine vergleichbare Logik mit eigener SessionID; auch der SAP-B1-Windows-Client hält eine Session gegen die Company-DB.
Abgrenzung
Session-Authentication ist kein Standard wie OAuth 2.0 oder OpenID Connect: Sie bindet Client und Server eng aneinander, macht horizontale Skalierung und stateless APIs aufwendiger und eignet sich deshalb weniger für öffentliche APIs mit vielen Consumern. Tokens (JWT, Bearer) übertragen ihre Gültigkeit und Claims selbst und sind damit zustandsloser. Gegenüber Basic Authentication ist Session-Authentication sicherer, weil Credentials nicht bei jedem Request mitgesendet werden — mit der Einschränkung, dass das Cookie selbst geschützt werden muss (HTTPS, HttpOnly, Secure, SameSite).
ReAct und RLEF: Wie Künstliche Intelligenz aus echten Fehlern lernt — und was der automatische Bankabgleich in SAP Business One damit zu tun hat
SAP B1 10.0 FP2608: Service Layer KI als transaktionalen Schicht
Process Reward Models: Warum ein richtiges Ergebnis noch keinen richtigen Weg beweist
Test-Time Compute Scaling: Warum ein kleineres KI-Modell am Ende gewinnen kann — und was der Lieferantenvergleich in SAP Business One damit zu tun hat
RLHF und Reward-Modelle: KI-Hype oder was der Genehmigungsprozess in SAP Business One damit zu tun hat
