OAuth, OpenID Connect und JWT - wie hängt das alles zusammen? (Teil 1)

Blog offline

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Wer Webanwendungen oder REST-APIs entwickelt bzw. eine verteilte Architektur à la Microservices einsetzt, ist vermutlich schon einmal mit den Themen Login, Authentifizierung und Autorisierung in Berührung gekommen. In diesem Zusammenhang sind vielleicht die Begriffe OAuth, OpenID Connect und JWT schon einmal aufgetaucht.

In zwei Artikeln wollen wir uns damit auseinandersetzen, was der Zweck dieser drei Standards ist, und wie sie miteinander zusammenhängen. Vorab sollten wir uns noch einmal in Erinnerung rufen, was die Unterschiede zwischen Login, Authentifizierung und Autorisierung sind:

Login: Prozess zur Initiierung einer Sitzung / Session eines Benutzers; bei verteilten Services ist oft ein Single Sign-On (SSO) aus Benutzersicht sinnvoll, anstatt sich bei jedem Service separat anmelden zu müssen.
Authentifizierung: Verifizierung der Identität, z.B. über Benutzername und Passwort
Autorisierung: Nach erfolgreicher Authentifizierung wird überprüft, inwieweit die notwendigen Berechtigungen zur Nutzung des/der Services gegeben sind. Erst dann wird der Zugriff erlaubt.

Mittels OAuth, OpenID Connect und JWT lassen sich diese drei Aspekte als Single Sign-On realisieren. Es ist aber weit mehr möglich, wie etwa das Abrufen von erweiterten Benutzerinformationen, die Nutzung von bestehenden Accounts bei anderen Anbietern ("Logge dich mit XYZ ein") etc. In diesem Artikel wollen wir zunächst OAuth näher betrachten. Wie OpenID Connect und JWT dann mit OAuth integriert werden bzw. aufeinander aufbauen, wird in einem zweiten Teil beleuchtet.

OAuth 2.0* (RFC 6749)

ist ein Protokoll zur Autorisierung für Web-, Desktop und Mobile Anwendungen. Dabei wird es einem Endbenutzer (Resource Owner) ermöglicht, einer Anwendung (Client) den Zugriff auf Daten oder Dienste (Resources) zu ermöglichen, die von einem Dritten (Resource Server) bereitgestellt werden. Insbesondere erhält der Client keinen Zugriff auf Authentifizierungsinformationen des Resource Owners, etwa Benutzernamen oder Passwörter.

[caption id="attachment_49138" align="alignnone" width="645"] Grafik: Rollen bei OAuth 2.0[/caption]

Neben den bereits erwähnten Rollen Resource Owner, Client und Resource Server, gibt es einen vertrauenswürdigen Authorization Server, der sicherstellt, dass sich der Resource Owner authentifiziert. Nach der Authentifizierung kann der Resource Owner den Client in einem (z.B. je nach Benutzerrolle) vorgegebenen Rahmen mit Zugriffsrechten ausstatten, d.h. autorisieren.

Es gibt vier Varianten des OAuth 2.0-Protokolls, die für unterschiedliche Einsatzszenarien gedacht sind. Wir wollen nun den Ablauf der Authorization Code-Variante etwas näher betrachten.

Authorization Code Flow

Typisches Einsatzszenario: Web-Applikation, Benutzer (=Resource Owner) verwendet Browser als User Agent; Client im Sinne von OAuth 2.0 ist ein Web-/Application Server, nicht der Browser.

Ablauf:

Der Client versucht auf eine geschützte Ressource zuzugreifen, hat jedoch keine Berechtigung. Der User Agent des Resource Owners wird auf den Authorization Server umgeleitet. (1)
Der Resource Owner authentifiziert sich gegenüber dem Authorization Server (vorher findet ein HTTP-Redirect vom Client statt) und autorisiert den Zugriff des Clients. (2)
Bei Erfolg: Einmal verwendbarer Freigabecode (Authorization Code) wird vom Authorization Server zugeteilt. (3)
Der Client erhält den Freigabecode (normalerweise per Redirect) und kann ihn (nach ggf. notwendiger Client-Authentifizierung) gegen ein Access Token - und ggf. ein Refresh Token - eintauschen. Beide Tokens besitzen eine begrenzte zeitliche Gültigkeit. (4-6)
Mit dem Access Token erhält der Client Zugriff auf die vorher vom Resource Owner freigegebene Ressource. (7-8)
Refresh Tokens können genutzt werden, um vom Authorization Server ein neues Access Token (und ggf. Refresh Token) nach dessen Ablauf anzufordern.

[caption id="attachment_49139" align="alignnone" width="708"] Grafik: Ablauf des OAuth 2.0 Authorization Code Flow[/caption]

Weitere Varianten

Implicit
Einsatzszenario: Der Client ist mit dem User Agent des Resource Owners identisch (z.B. Single Page Web Application, Rich Client); direkter API-Zugriff auf Resource Server (z.B. REST)
Besonderheiten: Ein Access Token wird direkt nach der Authentifizierung des Resource Owners vom Authorization Server ausgestellt. Refresh Tokens werden nicht ausgestellt. Das Access Token ist nicht vor dem Zugriff des Benutzers geschützt.
Resource Owner Password Credentials
Der Client ist aus Sicht des Resource Owners vertrauenswürdig; er erhält die Zugangsdaten des Resource Owners, mit denen er vom Authorization Server ein Access Token erhält.
Client Credentials
Nur Client-Authentifizierung; Resource Owner ist nicht beteiligt (z.B. zur Inter-Service-Kommunikation)

Was ist in OAuth 2.0 nicht festgelegt?

Viele Aspekte des Protokolls werden bewusst offen gehalten; müssen jedoch für eine Implementierung definiert werden. Es wird z.B. nicht festgelegt

wie die Tokens genau aussehen und wie sie verifiziert werden,
ob und wie Authorization Server und Resource Server kommunizieren,
wie der Client Benutzerinformationen erhalten kann,
wie die Benutzerauthentifizierung erfolgt oder
in welcher Form der Benutzer die Zugriffsrechte des Clients festlegen kann

Hinsichtlich der Tokens finden oft sogenannte Bearer Tokens Verwendung (RFC 6750). Diese ermöglichen jedem Besitzer ("Bearer") autorisierten Ressourcenzugriff. Es findet keine weitere Überprüfung statt. Die Verwendung von Bearer Tokens ist in OAuth 2.0 jedoch nicht vorgeschrieben.

JWT und OpenID Connect schließen viele der noch offenen Punkte der OAuth 2.0-Spezifikation. Wie das geschieht, betrachten wir in einem Folgeartikel.

* OAuth 1.0 sollte aufgrund von Sicherheitsmängeln nicht mehr verwendet werden. OAuth 2.0 unterscheidet sich grundlegend davon und ist nicht kompatibel.