© Ico Maker/shutterstock.com
Teil 3: OAuth 2.0 und die neuen Security-Best-Practices

Sichere Projekte mit Angular


OAuth 2.0 und das darauf aufbauende OpenID Connect erlauben das Anbinden von Identity-Lösungen wie Active Directory. Die OAuth 2.0 Security Best Current Practice schafft den bis dato für SPAs verwendeten Implicit Flow ab und erlaubt Refresh-Tokens.

Keine erstzunehmende Geschäftsanwendung kommt ohne Authentifizierung und Autorisierung aus. Schließlich muss die Anwendung ja wissen, mit wem sie es zu tun hat und welche Berechtigungen vorliegen. Eine sehr flexible Lösung hierfür ist der Einsatz von Securitytokens. Sie erlauben die Anbindung verschiedener Identity-Lösungen wie Active Directory und sind die Basis für die Realisierung von Single Sign-on.

Damit die Anwendung mit allen möglichen Identity-Lösungen funktioniert, benötigen wir ein wohldefiniertes Protokoll zur Kommunikation. Seit einigen Jahren sind OAuth 2.0 und OpenID Connect (OIDC) die De-facto-Standards dafür.

In diesem Artikel zeige ich, wie unsere Lösung aus den letzten beiden Teilen mit diesen Protokollen eine bestehende Identity-Lösung anbinden kann. Dabei berücksichtige ich die aktuellen Best Current Practices [1], an denen die OAuth Working Group gerade arbeitet und die in OAuth 2.1 einfließen sollen.

Das Beispiel dafür befindet sich wieder in meinem GitHub-Account [2]. Der Branch artikel3 beinhaltet die hier beschriebenen Anpassungen.

Überblick zu OAuth 2.0 und OpenID Connect

Das Prinzip hinter OAuth 2.0 und OIDC lässt sich sehr einfach mit dem sogenannten Implicit Flow visualisieren. Dabei handelt es sich um eine simple Spielart, die ursprünglich für Single Page Applications entworfen wurde. Der Flow beginnt damit, den Benutzer zu einem Authorization-Server umzuleiten (Abb. 1).

steyer_angular_start3_1.tif_fmt1.jpgAbb. 1: OAuth 2/OIDC Implicit Flow

Dieser Server kennt die einzelnen Konten und fordert den Benutzer auf, sich anzumelden. Die Art der Anmeldung ist ein Implementierungsdetail, das nicht vom Standard vorgegeben wird. Häufig kommen an dieser Stelle Benutzernamen und Passwörter zum Einsatz. Innerhalb von Windows-Domänen bietet sich auch die Nutzung der Windows-Authentifizierung an. Dabei erkennt der Authorization-Server ohne weitere Interaktion den aktuellen Windows-Benutzer.

Danach stellt der Authorization-Server ein sogenanntes Access-Token sowie ein ID-Token (Identity-Token) aus und leitet den Benutzer damit zurück zum Client, bei dem es sich in unserem Fall um eine Angular-Lösung handelt.

Das durch OIDC spezifizierte ID-Token informiert den Client über den aktuellen Benutzer. Es beinhaltet Key/Value Pairs – sogenannte Claims –, die den Benutzer beschreiben. Einige Keys sind durch OIDC standardisiert. Beispiele dafür sind given_name, family_name oder email.

Das ID-Token liegt per Definition als JSON Web Token (JWT) vor. Dabei handelt es sich – salopp formuliert – um ein BASE64-kodiertes JSON-Dokument. Somit kann es jeder Client einfach parsen und interpretieren.

Das Access-Token ist hingegen durch OAuth 2.0 definiert und gibt dem Client Zugriff auf das Backend, das die beiden Standards als Ressource-Server bezeichnen. Dazu inkludiert der Client das Token in einer HTTP-Kopfzeile. Da es sich beim Token um eine sensible Information handelt, ist hierbei – wie generell bei OAuth 2.0 und OIDC – auf HTTPS zu setzen.

Nachdem der Ressource-Server das Access-Token erfolgreich validiert hat, findet er darin Claims, die auf den Benutzer verweisen. Um herauszufinden, ob das Access-Token tatsächlich von einem vertrauenswürdigen Authorization-Server stammt, kommen häufig digitale Signaturen zum Einsatz. Alternativ dazu kann der Ressource-Server mit dem Authorization-Server Rücksprache halten, um sich darüber zu informieren, ob das Access-Token (noch) gültig ist. Ersteres ist einfacher und letzteres ist ein wenig sicherer, weil ständig geprüft wird, ob der Benutzer noch immer Zugriff hat.

Ein häufig praktizierter Mittelweg ist die Verwendung von kurzlebigen Access-Tokens. Wie im weiteren Verlauf beschrieben wird, muss der Client bei dieser Spielart regelmäßig ein neues Token abrufen. Dabei wird geprüft, ob der Benutzer nach wie vor die nötigen Berechtigungen hat.

Im Gegensatz zum ID-Token ist das Format des Access-Tokens nicht spezifiziert. Es kann jeden beliebigen Aufbau haben und ist für den Client nicht zwangsweise lesbar.

OAuth 2.0 Security Best Current Practice

Der im letzten Abschnitt zusammengefasste Implicit Flow war die Standardlösung in Single Page Applications seit dem Erscheinen der beiden Standards. Das Dokument „OAuth 2.0 Security Best Current Practice“, an dem die OAuth Working Group gerade arbeitet, ändert das. Dieses Dokument ebnet den Weg zu OAuth 2.1 und schlägt vor, den Implicit Flow generell nicht mehr zu nutzen.

Wer den Implicit Flow in bestehenden Lösungen nutzt, muss jedoch nicht in Panik ausbrechen: Kommt er wohlüberlegt gemeinsam mit den üblichen Best Practices zum Einsatz, hält er den bekannten Angriffen stand. Einige dieser Best Practices sind sogar durch OIDC vorgeschrieben, und jede vertrauenswürdige Bibliothek sollte sie berücksichtigen.

Ein Nachteil ist auch, dass der Implicit Flow die Tokens beim Redirect über URL-Parameter an den Client sendet (Abb. 1). Sie landen somit in der Browser-History, aber auch in den Logs des Authorizat...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang