OAuth2

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

OAuth 2.0 ist ein offener Standard für delegierte Autorisierung im Web: Eine Anwendung erhält im Namen eines Benutzers Zugriff auf Ressourcen eines anderen Dienstes, ohne dass der Benutzer sein Passwort an die Anwendung weitergibt. Stattdessen stellt ein Authorization Server ein kurzlebiges Access-Token aus, das die Anwendung im HTTP-Header (Authorization: Bearer …) an die Zielressource sendet.

Kontext

OAuth 2.0 kennt mehrere Flows, die für unterschiedliche Client-Typen gedacht sind: Authorization Code mit PKCE für Web- und mobile Apps, Client Credentials für Server-zu-Server-Kommunikation, Device Code für Geräte ohne Browser. Zusätzlich zum Access-Token kommt häufig ein Refresh-Token, mit dem abgelaufene Access-Tokens ohne neue Benutzerinteraktion erneuert werden. Access-Tokens tragen Scopes, die festlegen, welche Aktionen erlaubt sind — zum Beispiel nur lesend oder nur auf bestimmte Endpunkte. Im SAP-Business-One-Umfeld wird OAuth typischerweise dort eingesetzt, wo externe Systeme eingebunden werden: HubSpot, Snitcher, Microsoft 365, Peppol-Zugangspunkte, Mail- und Dokumentendienste. Der SAP-B1-Service-Layer selbst verwendet primär Session-Authentication; OAuth-basierte Wrapper-APIs können vor den Service Layer gesetzt werden, um B1-Daten sicher nach außen zu publizieren.

Abgrenzung

OAuth 2.0 ist Autorisierung, nicht Authentifizierung — für die Identität des Benutzers braucht es die Erweiterung OpenID Connect. Es ersetzt auch nicht die Verschlüsselung: HTTPS ist Voraussetzung, sonst sind Tokens abhörbar. Gegenüber API-Keys ist OAuth flexibler (scopeable, widerrufbar, kurzlebig), aber aufwendiger einzurichten. Und gegenüber SAML wirkt OAuth schlanker und API-freundlicher, bringt dafür aber weniger „out-of-the-box"-Strukturen für klassische Enterprise-SSO-Szenarien mit.