REST-API: Basic Authentication vs. OAuth 2.0

Bei der Arbeit mit unserer REST API können je nach Szenario und Sicherheitsanforderungen unterschiedliche Authentifizierungsmechanismen verwendet werden. 

Für einen vollständigen Überblick über alle Mechanismen konsultieren Sie bitte unseren Entwicklerleitfaden: API Guide | BOC Developer Portal

Zwei häufig genannte Methoden sind Basic Authentication und OAuth 2.0, da sie relativ unkomplizierte Ansätze bieten.

Obwohl beide Methoden den Zugriff auf die API ermöglichen, unterscheiden sie sich erheblich hinsichtlich Sicherheitsmodell, Konfigurationsaufwand und vorgesehenen Anwendungsfällen. Die Wahl der geeigneten Methode ist daher nicht nur eine technische Entscheidung, sondern hängt auch von den Sicherheitsrichtlinien Ihrer Organisation und der Art der Integration ab, die Sie umsetzen.
 

Wichtig: 
Die in diesem Artikel beschriebene Konfiguration muss mit Ihren internen Sicherheitsrichtlinien abgeglichen werden und bietet lediglich Best-Practice-Empfehlungen und Einblicke. 

Produktive Setups sollten stets von erfahrenen IT-Administratoren umgesetzt und überprüft werden.

Basic Authentication

Basic Authentication ist der einfachere der beiden Ansätze. Dabei werden bei jeder API-Anfrage Benutzername und Passwort mitgesendet. Dies macht die Einrichtung einfach und eignet sich für schnelle Tests oder einfache Integrationen.

Diese Einfachheit bringt jedoch Einschränkungen mit sich. Da die Anmeldedaten bei jeder Anfrage übertragen werden, gibt es keine Trennung zwischen Authentifizierung und Autorisierung über die zugewiesenen Benutzerrechte hinaus. Außerdem existiert kein Konzept für Token-Lebensdauer oder eingeschränkten Zugriff, was das Sicherheitsniveau im Vergleich zu OAuth reduziert.

Aus diesem Grund wird Basic Authentication in der Regel nur für nicht-produktive Szenarien oder kurzfristige Tests empfohlen.
 

Dokumentation: Basic Authentication aktivieren - BOC Docs

Anforderungen an Basic Authentication

Bei Verwendung von Basic Authentication müssen folgende Benutzerbedingungen erfüllt sein:

• Der Benutzer muss ein lokal definierter Benutzer im System sein. 
• Benutzer, die importiert wurden oder über Single Sign-On (SSO) authentifiziert werden, können in diesem Zusammenhang nicht verwendet werden. 
• Der Benutzer darf nicht als technischer Benutzer konfiguriert sein.
• Konfigurierter Repository-Zugriff.

Bei Verwendung von Basic Authentication müssen folgende Systembedingungen erfüllt sein:

Der Zugriff sollte auf Netzwerkebene eingeschränkt werden, indem nur bestimmte Client-IP-Adressen erlaubt sind: Authentifizierung. 

Bitte beachten Sie: Nach der Konfiguration muss ein Neustart der Umgebung ausgelöst werden: Umgebungs-Neustart Initiatoren

OAuth 2.0

OAuth 2.0 bietet einen moderneren und sichereren Authentifizierungsmechanismus und ist daher der empfohlene Ansatz für produktive Umgebungen.

Anstelle der Übertragung von Benutzeranmeldeinformationen verwendet OAuth Zugriffstoken. Diese Token können in Umfang und Lebensdauer begrenzt werden, was eine deutlich bessere Kontrolle über den Zugriff ermöglicht und das Risiko bei einer Offenlegung der Anmeldedaten verringert.

Dokumentation: OAuth 2.0 aktivieren - BOC Docs
 

OAuth 2.0 Flows

Je nach Integrationsszenario werden unterschiedliche OAuth-Flows verwendet: 

Client Credentials Grant Type | BOC Developer Portal
Der Client Credentials Flow wird typischerweise für die Kommunikation von System zu System verwendet. Dabei ist keine Benutzerinteraktion erforderlich, und die Authentifizierung erfolgt rein zwischen technischen Komponenten. Dies ist der häufigste Ansatz für Backend-Integrationen und automatisierte Prozesse.
 

Authorization Code Grant Type | BOC Developer Portal
Der Authorization Code Flow ist erforderlich, wenn ein echter Benutzerkontext benötigt wird. Dies ist typischerweise der Fall bei der Arbeit mit Single Sign-On (SSO), bei dem die Authentifizierung an einen Identity Provider delegiert wird. Nur dieser Flow ermöglicht eine ordnungsgemäße benutzerbasierte Authentifizierung in solchen Szenarien.

Anforderungen an den OAuth 2.0 Authorization Code Grant Type

Bei Verwendung von OAuth 2.0 müssen folgende Benutzerbedingungen erfüllt sein:

• Ähnlich wie bei Basic Authentication muss der beteiligte Benutzer ein lokal definierter Benutzer sein und darf nicht mit SSO verknüpft sein. 

• Dieser Benutzer muss explizit als technischer Benutzer in den Systemeinstellungen konfiguriert sein.

• „Trusted Login“ muss aktiviert sein.

• Konfigurierter Repository-Zugriff.

Bei Verwendung von OAuth 2.0 müssen folgende Systembedingungen erfüllt sein:

Der zweite Teil der Konfiguration erfolgt über den Connector, wo der OAuth-Client erstellt wird. Dabei werden die Client-ID und das Client-Geheimnis generiert, die später zur Erlangung von Zugriffstoken verwendet werden: Authentifizierung | ADONIS

Der Zugriff auf die API wird dann über Scopes gesteuert, welche genau definieren, welche Operationen erlaubt sind. Dies ermöglicht ein wesentlich klareres Autorisierungsmodell im Vergleich zur Basic Authentication.

Bitte beachten Sie: Nach der Konfiguration muss ein Neustart der Umgebung ausgelöst werden: Umgebungs-Neustart Initiatoren
 

Empfehlungen

Für produktive Umgebungen sollte aufgrund des verbesserten Sicherheitsmodells und der Flexibilität immer OAuth 2.0 bevorzugt werden.

Basic Authentication kann dennoch für schnelle Tests oder erste Setups nützlich sein, sollte aber in Umgebungen mit höheren Sicherheitsanforderungen nicht als langfristige Lösung betrachtet werden.

Die Erstellung separater OAuth-Clients gewährleistet eine klare Trennung der Zugriffsrechte und vereinfacht die Wartung. Änderungen können so auf eine einzelne Integration angewendet werden, ohne andere zu beeinflussen.