Session-Authentication

E-Rechnung in Deutschland: So setzen Sie die Pflicht mit SAP Business One um

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).