19. Juni 2019 in code IT

 OpenID Connect – Web Applications

Die meisten Web Applikation benötigen eine Authentifizierung von Benutzern, sowie eine Autorisierung dieser Benutzer für Aktionen und Ressourcen. Diese Authentifizierung und Autorisierung kann z. B. mit OpenID Connect (Nachfolger von OpenID), welches auf dem Protokoll OAuth 2.0 basiert, realisiert werden.

Was ist OpenID Connect?

OpenID Connect ist ein offenes und dezentrales Authentifizierungs- und Autorisierungssystem, welches das Protokoll OAuth 2.0 erweitert. Zur Autorisierung von geschützten Ressourcen nutzt man Tokens. Ein Token in OpenID Connect ist ein JSON Objekt mit Information. Es ist Base64 kodiert und kann validiert werden. Der OpenID Connect Provider (Authentifizierungssystem) liefert nach einer Authentifizierung einen Access-Token zum Autorisieren des Users, den Refresh-Token. Dieser wird benötigt zum Anfordern eines neuen Access-Tokens und den ID-Token für die User-Informationen. Dadurch, dass die Web-Applikation keine Authentifizierung durch Username und Passwort benötigt, ersparen sich die Web-Applikationen und die Ressourcen das sichere Verwahren und Verwalten dieser sensiblen Daten. Dadurch, dass OpenID Connect ein dezentrales Authentifizierungssystem ist, ist eine SSO (Single-Sign-On) leicht umsetzbar. Hinzu kommt, dass durch den Access-Token (eventuell noch der ID-Token) die REST API Schnittstelle alle nötigen User-Informationen zur Autorisierung des Benutzers für Aufgaben erhält (REST APIs sollten immer „Stateless“ sein).

Die verschiedenen Token-Arten

Der OpenID Connect Provider liefert nach erfolgreicher Authentifizierung drei Tokens: Access-Token, Refresh-Token und den ID-Token. Die Tokens sind normalerweise mit der Standard-Konfiguration nicht verschlüsselt. Sie enthalten immer eine Lebensdauer, sowie eine cryptographische Signatur. Durch die Lebensdauer und die Signatur im Token kann der Token lokal in der jeweiligen Ressource validiert werden.

Der Access-Token ist zum Autorisieren erforderlich und wird beim Aufruf der Ressource im Header unter „Authorization“ mit dem prefix „Bearer “ mitgegeben. Der Access-Token hat normalerweise eine geringe Gültigkeitsdauer und muss nach Ablauf neu angefordert werden.

Mit dem Refresh-Token kann vom OpenID Connect Provider ein neuer Access-Token angefragt worden, ohne dass eine weitere Authentifizierung nötig ist. Der Refresh-Token hat normalerweise eine längere Gültigkeitsdauer. Wenn der Access-Token und der Refresh-Token abgelaufen sind, muss sich der User neu authentifizieren.

Der ID-Token enthält die User-spezifischen Informationen als Key/Value-Paare. Der ID-Token ist auch gleichzeitig der JWT-Token (JSON Web Token). Die anderen Tokens können auch JWT-Token sein. Eine Attributzeile bzw. ein Key/Value-Paar mit den User-Information nennt man auch „claim“.

Der Ablauf der Authentifizierung

 Der Ablauf der Authentifizierung mit Open ID Connect

Beim ersten Zugriff auf eine geschützte Ressource wird der User auf die Authentifizierungsseite des OpenID Connect Providers weitergeleitet. Nachdem der User erfolgreich authentifiziert wurde, wird der User zurück auf den Client weitergeleitet und erhält die drei Tokens (Access-Token, Refresh-Token und ID-Token). Der Client kann mit dem Access-Token die geschützen Ressourcen aufrufen (falls der Access-Token keine User-Informationen enthält, muss der ID-Token auch noch mitgegeben werden). In der Ressource wird der Access-Token validiert und nach erfolgreicher Validierung die benötigten User-Informationen aus dem JWT-Token geclaimed. Bei erneuter Anfrage einer geschützten Ressource und einem nicht mehr gültigem Access-Token wird der Access-Token über den Refresh-Token neu angefordert. Wenn auch der Refresh-Token abgelaufen ist, muss der User sich wieder neu authentifizieren.

 

Ein Beispiel Szenario zur Nutzung von Token

Beispielszenario zur Nutzung von Tokens

Gegeben:

  • User besitzt bei Keycloak einen User-Account und hat die benötigten Rechte, um seine Rechnung einzusehen
  • In der Web-App gibt es den Button „Letzte Rechnung“
  • Die REST API für Rechnungen ist geschützt

Szenario:

  1. Der User startet die Web-App und klickt auf den Button „Letzte Rechnung“
  2. Die Web-App validiert Token:
    1. Access-Token ist noch valide: Weiter zu 3.
    2. Access-Token ist abgelaufen, aber das Refresh-Token ist noch valide:
      Web-App fordert mit dem Refresh-Token von Keycloak neue Tokens an
    3. Keine Tokens vorhanden oder abgelaufen:
      Die Web-App leitet auf die Authentifizierungsseite von Keycloak weiter
  1. Der User loggt sich ein und wird zurück auf die Ursprungsseite weitergeleitet
  2. Die Web-App macht einen REST-Aufruf (mit Access-Token) zur Rechnungs-Ressource
  3. Die Ressource validiert den Access-Token
  4. Die Ressource claimed aus dem JWT-Token (in dem Fall aus dem Access-Token) die Kundennummer
  5. Die Ressource sendet die Rechnung als Antwort zurück
  6. Die Web-App zeigt die Rechnung an

Benjamin Koopmann, Entwickler bei objective partner

Artikel von Benjamin Koopmann

Zurück zur Übersicht