OAuth und OpenID - Effiziente Autorisierung und Authentifizierung

In der heutigen digital vernetzten Welt ist Datenschutz von entscheidender Bedeutung. Um unsere Daten effektiv zu schützen und Benutzer zu identifizieren, spielen die Protokolle OAuth und OpenID eine entscheidende Rolle. In diesem Blogbeitrag werde ich mich speziell diesen beiden Protokollen widmen und erläutern, wie sie funktionieren. Ausserdem werde ich aufzeigen, welche Sicherheitsfaktoren zu beachten sind, um ihre optimale Funktionalität und Sicherheit zu gewährleisten.

Dieser Beitrag ist Teil einer umfassenderen Auseinandersetzung mit dem Thema Webapplikationssicherheit, zu dem wir einen zweitägigen Workshop besucht haben. Der Workshop wurde von Urs Müller und Mischa Bachmann von der Firma Compass Security geleitet und hat uns wertvolle Erkenntnisse geliefert. Basierend auf diesen Erkenntnissen haben wir bereits zwei Beiträge verfasst, einen über JSON Web Tokens und einen über die Authentifizierung mittels HTTP-Formularen.

Nun ist es an der Zeit, uns mit den OAuth- und OpenID-Protokollen auseinanderzusetzen. Diese Protokolle bieten uns sichere und effektive Methoden zur Verwaltung des Zugriffs auf unsere Daten und zur Identifizierung von Benutzern. In diesem Beitrag werde ich detailliert erklären, wie diese Protokolle funktionieren und welche Sicherheitsaspekte dabei zu beachten sind.

Ich hoffe, dass dieser Beitrag Ihnen einen umfassenden Einblick in die Thematik der OAuth- und OpenID-Protokolle bietet und Ihnen dabei hilft, Ihre Webapplikationen sicherer zu gestalten.

Autorisierung anderer Apps auf geschützte Ressourcen

OAuth ist ein verbreitetes Protokoll, das sichere Autorisierungsmethoden für webbasierte Anwendungen bereitstellt. Es ermöglicht einer Anwendung (Client), auf geschützte Ressourcen eines Benutzers auf einem anderen Server (Provider) zuzugreifen, ohne dass der Benutzer dem Client seine Login-Daten geben muss. Der OAuth-Ablauf beinhaltet vier Teilnehmer: der Benutzer, der Client, der Ressourcen-Server und der Authentifizierungsserver.

Grant-Typen in OAuth

OAuth Definiert verschiedene Methoden wie eine Autorisierung durchgeführt wird, auch genannt Grants. 
Die wichtigsten vier sind:

1. Authorization Code Grant

Beim Authorization Code Grant erhält der Client einen Autorisierungscode vom Provider, um Zugriffstoken anzufordern. Dieser Grant-Typ ist geeignet für interaktive Anwendungen und bietet zusätzliche Sicherheitsmechanismen wie den Proof Key for Code Exchange (PKCE), um sicherzustellen, dass der Client, der das Zugriffstoken erhält, auch derjenige ist, der die Autorisierung gestartet hat.

2. Implicit Grant

Beim Implicit Grant erhält der Client das Zugriffstoken direkt vom Autorisierungsendpunkt, ohne zuerst den Autorisierungscode zu bekommen. Dieser Grant-Typ, birgt ein etwas höheres Sicherheitsrisiko und ermöglicht keine Überprüfung, ob der richtige Client das Token erhalten hat.

3. Resource Owner Password Credentials Grant

Beim Resource Owner Password Credentials Grant geht der Benutzername und das Passwort direkt an den Client weiter, was als weniger sicher gilt und nicht mehr empfohlen wird.

4. Client Credentials Grant

Beim Client Credentials Grant authentifiziert sich der Client selbst gegenüber dem Provider, um Zugriff auf Ressourcen zu erhalten. Es erfolgt keine Interaktion mit dem Benutzer. Diese Methode wird häufig für die Backend-zu-Backend-Kommunikation verwendet.

Heutzutage werden der Authorization Code Grant mit PKCE für interaktive Anwendungen und der Client Credentials Grant für Maschinen-zu-Maschinen-Kommunikation empfohlen. Wenn eine Anwendung weiterhin den Implicit Grant oder den Authorization Code Grant ohne PKCE verwendet, besteht möglicherweise noch keine direkte Bedrohung, aber ein Wechsel zu Authorization Code Grant mit PKCE sollte in naher Zukunft erfolgen. Wenn noch der Resource Owner Password Credentials Grant verwendet wird, sollte möglichst schnell auf den Authorization Code Grant mit PKCE umgestellt werden.

Die Sicherheitsaspekte in den OAuth Schritten

Sicherheit ist ein wichtiger Aspekt beim OAuth-Protokoll. Hier werden die Sicherheitsaspekte der einzelnen Schritte etwas detaillierter erklärt:

1. Client-Registrierung: Bei der Registrierung des Clients beim Autorisierungsserver erhält der Client eine eindeutige ID und gegebenenfalls ein Secret. Diese Informationen dienen dazu, den Client in Zukunft zu identifizieren. Das Secret bietet zusätzliche Sicherheit, da es als geheimes Passwort fungiert. Allerdings ist das Secret für öffentliche Anwendungen wie Websites nicht erforderlich, da es in solchen Fällen von jedermann ausgelesen werden kann. Die genaue Struktur der Registrierung ist nicht in der OAuth-Spezifikation festgelegt, aber die meisten Implementierungen bieten zusätzliche Sicherheitsparameter, wie den Signieralgorithmus für ausgetauschte JSON Web Tokens (JWT).
2. Autorisierung: Beim Autorisierungsschritt wird der Benutzer zur Autorisierung aufgefordert. Der Autorisierungsserver überprüft dabei, ob die mitgegebenen Informationen, wie die Callback-URL und die Client-ID, mit den während der Registrierung gespeicherten Angaben übereinstimmen. Die Zustimmung des Benutzers ist ein wichtiger Sicherheitsaspekt, da sie sicherstellt, dass der Benutzer bewusst seine Daten freigibt.
3. Validierung des Autorisierungscode: Der Client kann beim Autorisierungsantrag einen Zustand (state) übergeben, der vom Autorisierungsserver beim Callback zurückgegeben wird. Der Client verwendet diesen Zustand, um sicherzustellen, dass der Autorisierungsantrag tatsächlich von ihm gestellt wurde. Dies hilft, potenziellen Missbrauch zu verhindern, da es verhindert, dass unbefugte Personen den Autorisierungsprozess weiterführen.
4. Anfordern des Access Tokens: Beim Anfordern des Access Tokens überprüft der Autorisierungsserver, ob der Client die richtige Client-ID und das Secret (falls vorhanden) mitgesendet hat. Es wird auch überprüft, ob der übermittelte Autorisierungscode bereits verwendet wurde oder abgelaufen ist. Wenn PKCE verwendet wird, wird zusätzlich überprüft, ob der anfragende Client derselbe ist, der den Autorisierungscode erhalten hat. Diese Überprüfungen stellen sicher, dass nur autorisierte Clients Zugriff erhalten und dass die Kommunikation sicher ist.
5. Zugriff auf die geschützte Ressource: Nachdem der Client den Access Token erhalten hat, kann er damit auf die geschützte Ressource zugreifen. Der Ressourcen-Server überprüft das Token, um sicherzustellen, dass es gültig ist und, dass der Client die Berechtigung hat, auf den angeforderten Teil der Ressource zuzugreifen. Die Validierung des Tokens durch den Ressourcen-Server und die Verwendung eines Signaturalgorithmus gewährleisten, dass das Token nicht manipuliert wurde und schützen vor unbefugtem Zugriff auf die geschützte Ressource.

Eine Standardisierung der Authentifizierung

Das OAuth Protokoll bietet sich an auch zum Authentifizieren verwendet zu werden, statt nur zum Autorisieren. Genau dies wurde mit OpenID Connect standardisiert. Der Standard führt ein neues Token ein, das sogenannte Id Token. Damit OpenID, welches auf OAuth läuft, getriggert wird, muss im Scope der Anfrage an Autorisierung Endpunkt der scope “openid” angefordert werden.

Das ID Token

Bei OpenID gibt es zusätzlich zum Autorisierungscode und dem Zugriffstoken das ID Token. Dieses Token enthält grundlegende Informationen über den Endbenutzer und ist im Format eines JSON Web Tokens (JWT) strukturiert. Es enthält nicht nur Informationen über den Benutzer, sondern auch Angaben über den Aussteller des Tokens, für welche Anwendung das Token erstellt wurde und seine Gültigkeitsdauer.

Das Ziel des ID Tokens besteht darin, dass eine Anwendung Informationen über die Identität des Benutzers erhält, um ihm eine personalisierte Benutzererfahrung bieten zu können. Es ist jedoch wichtig zu beachten, dass ein ID Token nicht für die Autorisierung oder für den Zugriff auf eine API verwendet werden sollte. Falls diese Funktionen erforderlich sind, sollte immer auch ein Access Token angefordert werden.

Wenn wir ein ID Token empfangen, ist es von entscheidender Bedeutung, es zu validieren. Zunächst müssen wir es entschlüsseln, falls es verschlüsselt ist. Anschliessend prüfen wir den Aussteller und die Zielgruppe des Tokens, um sicherzustellen, dass sie korrekt sind. Danach überprüfen wir die Gültigkeit und das Ablaufdatum des Tokens. Zusätzlich muss das JWT selbst validiert werden, um sicherzustellen, dass es echt und nicht manipuliert wurde. Falls bei der Anfrage ein Nonce (eine Zufallskennung) angegeben wurde, sollte dieser auch im Token enthalten sein und überprüft werden.

OpenID Process Flows

OpenId bietet wie OAuth ein Authorization Code Grant, der im Bild unten dargestellt ist und ein impliziten flow, der auch analog zum Implicit Grant von OAuth direkt das ID Token sowie eventuell ein Zugriffstoken zurück gibt, ohne erst einen Autorisierungscode auszustellen. Der Standard definiert auch Hybrid-Workflows, die verschiedene Kombinationen dieser Rückgabewerte verwenden. Achtung, nicht alle OpenID-Implementierungen unterstützen diese hybriden Workflows.

Fazit

OAuth ist ein Protokoll zur sicheren Autorisierung von webbasierten Anwendungen und ermöglicht es Anwendungen, auf geschützte Ressourcen zuzugreifen, ohne dass der Benutzer dem Client seine Login-Daten geben muss. Es definiert verschiedene Grant-Typen, um die Sicherheit zu gewährleisten. OpenID Connect erweitert OAuth, um das ID Token, das grundlegende Informationen über den Benutzer enthält und für die Identitätsüberprüfung verwendet wird. Die Verwendung dieser Protokolle erleichtert die Entwicklung und Wartung von Anwendungen, verbessert die Sicherheit und führt zu einer konsistenten Benutzererfahrung.

Weitere Informationen finden Sie in RFC 6819, das detaillierte Informationen zu den Sicherheitsaspekten von OAuth enthält. Wenn es aus bestimmten Gründen nicht möglich ist, OAuth und OpenID Connect zu verwenden, empfehle ich die Lektüre unseres Beitrags zu http forms, der alternative Ansätze zur Autorisierung und Validierung von Benutzern behandelt. Darüber hinaus können Sie auch unseren Beitrag zu JWT lesen, um mehr darüber zu erfahren, wie diese aufgebaut sind.