Warum du den Resource Owner Password Credentials (ROPC) Grant-Typ veraltet lassen solltest

Einführung#

Der Resource Owner Password Credentials (ROPC) Grant-Typ alias Passwort-Grant-Typ ist ein OAuth 2.0-Flow, der es einer Anwendung ermöglicht, den Benutzernamen und das Passwort eines Benutzers gegen ein Zugriffstoken auszutauschen. Er wurde in der OAuth 2.0-Spezifikation erstmals eingeführt, um alte Anwendungen wie die HTTP-Basis-Authentifizierung oder alte native Anwendungen zu unterstützen, die nicht die sichereren tokenbasierten OAuth-Flows verwenden konnten.

Der ROPC-Grant-Typ birgt jedoch mehrere Sicherheitsrisiken und wurde in den OAuth 2.0-Sicherheitsmethoden als MUSS NICHT verwendet werden markiert.

In letzter Zeit haben wir einige Anfragen von Kunden erhalten, die Unterstützung bei der Implementierung des ROPC-Grant-Typs erbeten haben. In diesem Beitrag werden wir erklären, warum du die Verwendung des ROPC-Grant-Typs insbesondere für deine neuen Anwendungen vermeiden solltest.

ROPC-Grant-Typ vs. Autorisierungscode-Flow#

Wie der ROPC-Grant-Typ funktioniert#

Der ROPC-Grant-Typ ist ein einfacher Flow, der den Benutzernamen und das Passwort des Benutzers gegen ein Zugriffstoken austauscht. Die Client-Anwendung sammelt die Anmeldeinformationen des Benutzers direkt und sendet sie direkt an den Autorisierungsserver. Der Autorisierungsserver validiert dann die Anmeldeinformationen und stellt dem Client ein Zugriffstoken aus.

Wie der Autorisierungscode-Flow funktioniert#

Im Gegensatz dazu ist der Autorisierungscode-Flow der empfohlene OAuth 2.0-Flow für Webanwendungen. Es werden mehrere Schritte und Umleitungen zwischen der Client-Anwendung, dem Autorisierungsserver und dem Browser des Benutzers durchgeführt. Der Autorisierungscode-Flow ist sicherer, da er die Anmeldeinformationen des Benutzers nicht der Client-Anwendung aussetzt.

Die Hauptunterschiede zwischen dem ROPC-Grant-Typ und dem Autorisierungscode-Flow liegen darin, dass ROPC die Benutzeranmeldeinformationen der Client-Anwendung aussetzt, während der Autorisierungscode-Flow dies nicht tut. Benutzeranmeldeinformationen sollten vertraulich auf dem Autorisierungsserver aufbewahrt werden. Wann immer eine Client-Anwendung eine Ressource im Namen des Benutzers anfordert, sollte sie den Benutzer zur Authentifizierung und Autorisierung der Client-Anwendung an den Autorisierungsserver umleiten. Dadurch wird eine minimale Menge an Autorisierungsdaten auf der Seite der Client-Anwendung behalten.

Sicherheitsrisiken des ROPC-Grant-Typs#

1. Exposition der Benutzeranmeldeinformationen#

Wie bereits erwähnt, setzt der ROPC-Grant-Typ die Anmeldeinformationen des Benutzers der Client-Anwendung aus. Dies ist ein erhebliches Sicherheitsrisiko, da die Client-Anwendung die Anmeldeinformationen des Benutzers speichern oder protokollieren und ohne das Wissen des Benutzers erneut autorisieren kann.

Insbesondere bei einer öffentlichen Client-Anwendung wie einer mobilen Anwendung oder einer Single-Page-Anwendung kann die Client-Anwendung leicht injiziert oder rückentwickelt werden, um die Anmeldeinformationen des Benutzers zu extrahieren. Weder eine mobile Anwendung noch eine Single-Page-Anwendung, die im Browser des Benutzers läuft, können Geheimnisse vertraulich halten. Daher können sie den Benutzer nicht authentifizieren, ohne die Anmeldeinformationen des Benutzers preiszugeben.

Selbst wenn der Ressourcen-Besitzer eine vertrauensvolle Beziehung zu der Client-Anwendung hat, spielt die Client-Anwendung eine Man-in-the-Middle-Rolle im gesamten Authentifizierungsprozess und könnte von einem anderen böswilligen Akteur kompromittiert werden. Der böswillige Akteur kann die Anmeldeinformationen des Benutzers stehlen und sich als Benutzer ausgeben, um auf Ressourcen des Benutzers zuzugreifen.

Es gibt verschiedene Möglichkeiten, die Anmeldeinformationen des Benutzers zu stehlen, basierend auf der Sicherheitslage der Client-Anwendung, wie Keylogger, Phishing-Angriffe oder Malware. Abgesehen davon, dass die Client-Anmeldeinformationen bei jeder Autorisierungsanfrage über das Netzwerk übertragen werden, erhöht sich das Risiko einer Abfangung der Anmeldeinformationen noch weiter.

Stellen dir vor, du hast mehrere Anwendungen, die den ROPC-Grant-Typ verwenden, das potenzielle Risiko einer Exposition der Anmeldeinformationen vervielfacht sich.

2. ROPC unterstützt keine Benutzerzustimmung#

Der ROPC-Grant-Typ unterstützt keine Benutzerzustimmung. Wenn die Client-Anwendung die Anmeldeinformationen des Benutzers direkt sammelt, hat der Benutzer keine Möglichkeit, die Zugriffsrechte der Client-Anwendung auf seine Ressourcen zu überprüfen und zu genehmigen. Dies ist eine Verletzung der Privatsphäre und des Vertrauens des Benutzers.

Benutzer sollten das Recht haben zu entscheiden, welche Client-Anwendung auf welche Ressourcen zugreifen darf und wie lange. Insbesondere für Anwendungen von Drittanbietern ist ein Mechanismus zur Benutzerzustimmung unerlässlich, um die Daten des Ressourcen-Besitzers zu schützen und zur Einhaltung von Datenschutzbestimmungen wie der GDPR.

3. ROPC unterstützt keine Multi-Faktor-Authentifizierung#

Die Multi-Faktor-Authentifizierung (MFA) ist eine Sicherheitsmaßnahme, die Benutzer dazu verpflichtet, zwei oder mehr Verifikationsfaktoren bereitzustellen, um auf ihre Ressourcen zuzugreifen. Sie fügt dem Authentifizierungsprozess eine zusätzliche Sicherheitsebene hinzu. Der ROPC-Grant-Typ unterstützt keine MFA. Stattdessen beschränkt er den Authentifizierungsprozess auf einen einzigen Faktor, und die Token-Anfrage basiert ausschließlich auf den Anmeldeinformationen des Benutzers. Es ist unmöglich, mit dem ROPC-Grant-Typ Challenge-basierte Authentifizierungsmechanismen wie SMS-OTP, E-Mail-OTP oder WebAuthn zu implementieren.

ROPC ist nicht mit modernen Anwendungen kompatibel#

Der ROPC-Grant-Typ wurde entwickelt, um alte Anwendungen zu unterstützen, die moderne IAM-Systeme für Single Sign-On (SSO) oder föderierte Identitäten nicht unterstützen können.

1. ROPC ist nicht mit SSO kompatibel#

Single Sign-On (SSO) ist eine moderne Authentifizierungsarchitektur, die es Benutzern ermöglicht, sich einmal anzumelden und mühelos auf mehrere Anwendungen zuzugreifen.

Ein zentrales IdP spielt eine entscheidende Rolle in der SSO-Architektur. Es verwaltet die Authentifizierungssitzung des Benutzers und stellt Tokens für die Client-Anwendungen aus. Die Client-Anwendungen müssen die Benutzeranmeldeinformationen nicht direkt sammeln, und die Anmeldeinformationen des Benutzers bleiben vertraulich im IdP.

Der ROPC-Grant-Typ unterstützt kein SSO. Er erfordert, dass die Client-Anwendung die Anmeldeinformationen des Benutzers direkt sammelt, was die SSO-Architektur unterbricht. Es ist nicht mit modernen SSO-Systemen wie OpenID Connect (OIDC) oder SAML kompatibel.

2. ROPC ist nicht mit föderierten Identitäten kompatibel#

Ähnlich zur SSO-Architektur ermöglichen föderierte Identitäten den Benutzern, ihre bestehenden Identitäten zu nutzen, um auf mehrere Drittanbieter-Anwendungen zuzugreifen. Ein Benutzer kann mehrere soziale Accounts wie Google, Facebook oder Twitter an ein zentrales IdP verknüpfen und diese sozialen Accounts zur Authentifizierung bei den Client-Anwendungen verwenden. Alle föderierten Identitäten werden vom IdP verwaltet, und die Client-Anwendungen kennen die Authentifizierungsdetails des Benutzers unter der Haube nicht.

Der ROPC-Grant-Typ hingegen verlangt, dass die Client-Anwendung die Anmeldeinformationen des Benutzers direkt sammelt. Dies schränkt die Fähigkeit der Client-Anwendung ein, föderierte Identitäten zu unterstützen, und setzt die Identitätsdaten des Benutzers der Client-Anwendung aus.

Fazit#

Der Resource Owner Password Credentials (ROPC) Grant-Typ ist ein alter OAuth 2.0-Flow, der erhebliche Sicherheitsrisiken birgt und veraltet sein sollte. Er setzt die Benutzeranmeldeinformationen der Client-Anwendung aus und unterstützt keine modernen Sicherheitsmechanismen wie MFA oder SSO. Wir empfehlen dringend, den ROPC-Grant-Typ in deinen Anwendungen zu vermeiden. Wenn du alte Authentifizierungssysteme hast, die auf dem ROPC-Grant-Typ basieren, solltest du eine Migration zu sichereren OAuth 2.0-Flows wie dem Autorisierungscode-Flow oder dem Client-Credentials-Flow in Betracht ziehen.

Kontaktiere uns, wenn du Hilfe bei der Integration eines sicheren Benutzerauthentifizierungs- und Autorisierungsdienstes in deine Anwendungen benötigst oder wenn du von einem alten passwortbasierten Authentifizierungssystem auf einen sichereren OAuth 2.0-Flow migrieren möchtest. Wir sind hier, um dir zu helfen, sichere und moderne Anwendungen zu entwickeln.