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

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.

Im ersten Artikel zum Thema Authentifizierung und Autorisierung in Webanwendungen haben wir als einen Baustein das Protokoll OAuth 2.0 näher betrachtet. Die Spezifikation von OAuth 2.0 lässt viele Implementierungsdetails bewusst offen. Mit JSON Web Tokens (JWT) und OpenID Connect liegen zwei Standards vor, die OAuth 2.0 sinnvoll ergänzen.

JSON Web Tokens (JWT, RFC 7519)

JWT ist ein in sich geschlossenes, kompaktes Format, um Informationen als JSON-Objekt auszutauschen. Es unterstützt kryptographische Signaturen und optional Verschlüsselung. Es kann sowohl für Access und Refresh Tokens als auch zum Informationsaustausch verwendet werden. In OpenID Connect (siehe unten) wird es genutzt, um Benutzerinformationen zu übertragen.

Die Signatur stellt sicher, dass die Tokens auf dem Weg zum Empfänger nicht verändert wurden und tatsächlich vom Ersteller (z.B. Authorization Server) stammen. Wenn man JWT beispielsweise für OAuth Access Tokens verwendet, ist zur Verifikation der Token-Gültigkeit keine Anfrage beim Authorization Server notwendig, da die Token-Signatur lokal mit Hilfe des Public Keys des Authorization Servers überprüft werden kann.

JWTs bestehen aus Header, Payload und Signatur, die Base64-kodiert übertragen werden und durch Punkte getrennt sind.

Zum Beispiel repräsentiert das folgende Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

nachstehenden JSON-Inhalt:

Header: 
{
"alg": "HS256",
"typ": "JWT"
}

Payload:
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

Der Header gibt Auskunft über Signatur- oder Verschlüsselungsalgorithmus, sowie den Typ des Tokens. Die einzelnen Einträge im Payload werden Claims genannt. Davon sind in RFC 7519 einige vordefiniert (Bezeichnung: Registered Claims). sub steht beispielsweise für den Subject Identifier, d.h. die Instanz auf die sich das JWT bezieht. iat representiert den Ausstellungszeitpunkt ("Issued At"). Weitere definieren Ablaufzeitpunkt, Aussteller etc.

Die IANA stellt eine Datenbank bereit, die dazu dient, sogenannte Public Claims bekannt zu machen und Konflikte zu vermeiden. Jederzeit ist es möglich, eigene Claims zu definieren. Diese sollten besser nicht mit den Registered oder Public Claims kollidieren.

Der Aufbau verschlüsselter JWTs ist komplizierter und würde den Rahmen dieses Beitrags sprengen. Eine Kombination von Verschlüsselung und Signatur ist auch möglich, indem man JWTs schachtelt.

OpenID Connect

ist eine Authentifizierungs- und Identitätsschicht oberhalb von OAuth 2.0. OpenID Connect (OIDC) ermöglicht beispielsweise Clients, Informationen über den Benutzer zu erhalten sowie dessen Identität zu überprüfen. Sämtliche Informationen werden als JSON-Objekte ausgetauscht.

[caption id="attachment_49230" align="alignnone" width="270"] OpenID Connect setzt auf OAuth 2.0 und JWT auf[/caption]

OIDC definiert dabei weitere Registered Claims für Benutzerinformationen und definiert Vorgaben für bestimmte JWT-Attribute. Die so definierten Tokens werden ID Tokens genannt. ID Tokens werden zusätzlich zu Access und Refresh Tokens vom Authorization Server ausgestellt.

[caption id="attachment_49140" align="alignnone" width="516"] Grafik: Erweiterung von OAuth 2.0 durch OpenID Connect[/caption]

/userinfo Schnittstelle

OpenID Connect spezifiziert eine API zum Zugriff auf Benutzerinformationen unter Verwendung von Access Tokens. Diese wird vom Authorization Server bereitgestellt und liefert Informationen zum jeweiligen Benutzer, auf die der Client zugreifen darf. Welche dies sind, wird in der OAuth 2.0-Autorisierungsphase festgelegt.

Erweiterung des OAuth 2.0 Authorization Request

Der OAuth 2.0 Authorization Request wird um den Parameter  Scope erweitert. Hiermit kann festgelegt werden, auf welche Informationen des Benutzers der Client zugreifen darf. Beispiele für definierte Scopes sind email, address, phone oder profile. Der letztgenannte Scope erlaubt den Zugriff auf eine ganze Reihe von Profilinformationen des Benutzers, wie beispielsweise auch Namen, Geschlecht und Geburtsdatum.

Weiterhin ist es möglich, detailliert zu spezifizieren, welche Daten im ID Token und per /userinfo geliefert werden dürfen. Hierzu kann der Parameter claims dem Authorization Request hinzugefügt werden. Dieser ist eine JSON-Struktur und könnte beispielsweise wie folgt aussehen:

Die angeforderten Zugriffsrechte stellen lediglich eine Empfehlung an den Authorization Server/Benutzer dar. Somit können auch als "essential" markierte Claims verweigert werden. Die Angabe "essential" kann aber z.B. genutzt werden, um dem Benutzer anzuzeigen, dass die Anwendung wahrscheinlich nicht korrekt funktioniert, wenn er diese Daten nicht freigibt.

Fazit

OAuth, JWT und OpenID Connect bilden zusammen eine solide Basis für interoperable Implementierungen und Schnittstellen zur Authentifizierung und Autorisierung von webbasierten Anwendungen. Sie können anbieterübergreifend und -unabhängig eingesetzt werden. Es gibt fertige, frei verfügbare Open Source-Implementierungen für Authorization Server, wie beispielsweise Keycloak, die einen riesigen Funktionsumfang bieten, aber richtig konfiguriert und an die eigene Software angebunden werden müssen. Eine gewisse Grundkenntnis der Protokolle, Parameter und Formate ist hierzu unbedingt erforderlich.