‏ ‏ ‎ ‏ ‏ ‎

BACK to Index

1. Vorwissen

  • Was ist ein verteiltes System?

Zusammenschluss unabhängiger Computer, die sich für den Benutzer als ein einziges System präsentieren.

distributed systems 0

distributed systems 1

  • Warum müssen in verteilten Systemen Nachrichten übertragen werden?

    • Kommunikation

    • Koordination

    • Konsistenz

    • Fehlertoleranz

    • Skalierbarkeit

    • Transparenz

  • Asymmetrische Verschlüsselung (public-private key-pair)

    • Public- Private Key Pair

  • OAuth2 (basic)

    • OAuth2 ist ein offenes Protokoll, das es ermöglicht, in einer standardisierten Weise den Zugriff auf Webdienste zu delegieren, ohne dass der Benutzer seine Zugangsdaten weitergeben muss.

  • OpenIDConnect (basic)

    • OpenID Connect (OIDC) ist ein Identitätsauthentifizierungsprotokoll, das eine Erweiterung der offenen Autorisierung (OAuth) 2.0 darstellt, um den Prozess der Authentifizierung und Autorisierung von Benutzern zu standardisieren, wenn sie sich anmelden, um auf digitale Dienste zuzugreifen.

2. Lernziele

  • JWT

    • Was sind JWTs?

    • Wie sieht ein JWT aus?

    • Welche Probleme lösen sie?

    • Wie funktioniert das Signieren?

  • OAuth2 / OpenID Connect (OIDC)

    • Wie wird ein JWT bei OAuth-Authorization verwendet?

    • Was ist ein Access-Token?

      • Wozu braucht man ihn?

      • Wie wird er verwendet?

    • Was ist ein Refresh-Token?

      • Wozu braucht man ihn?

      • Wie wird er verwendet?

3. Sinn von JWT

  • Sichere Übertragung von Informationen über JSON

    • Datenübertragung

      • Sichere Übertragung von Daten

    • Authorisation

      • Wenn ein Benutzer eingeloggt ist, enthält von da an jeder Request einen JWT (bearer-token). Dieser enthält die Identität des Benutzers (Identity - Wer bin ich?) und dessen Rechte (Claims - Anrechte).

3.1. Was heißt Sicher?

  • Integrität

    Ist das die Nachricht von meinem Gegenüber, oder wurde diese abgefangen und verändert?

    → signieren (Header + Payload)

  • Geheimhaltung

    Niemand, außer dem Empfänger, soll die Übertragung lesen können.

    → verschlüsseln (gesamten Token)

    Ist nicht die Norm. Normalerweise wird nur signiert. Wenn ihr verschlüsseln wollt, müsst ihr euch selber darum kümmern.

Hier JWT - Group Puzzle beginnen, oder mit normalen Vortrag hier weitermachen.

4. Aufbau und Inhalt eines JWT

  • Identity (Identität)

    • Benutzerdaten

      • Name

      • Email

      • …

  • Claims (Anrechte)

    • Zum Beispiel das Recht…

      • … in der UI …

        • … eine gewisse Aktion ausführen zu dürfen

        • … einen Bildschirm zu sehen

        • … eine detailliertere Ansicht zu haben

        • …

      • … im Backend…

        • … einen Datensatz abzufragen

        • … einen Datensatz zu ändern

        • … einen Datensatz zu löschen

        • …

4.1. Struktur

  • Header

    • Welcher Signaturalgorithmus wird verwendet?

    • Typ des Tokens (meistens 'JWT')

    • Base64Url encoded

  • Inhalt (Payload)

    • Anrechte (Claims)

    • Base64Url encoded

  • Signatur

    Verschlüsselungsalgorithmus(
	base64UrlEncode(header) + "." +
	base64UrlEncode(payload),
	secret
)

    In der Form: xxxxx.yyyyy.zzzzz

    Siehe: https://jwt.io/#debugger-io

jwt 0

5. Typische Verwendung

5.1. OAuth2

jwt 1

  1. Die Anwendung oder der Client fordert beim Autorisierungsserver eine Berechtigung an. Dies erfolgt über einen der verschiedenen Autorisierungsabläufe. Beispielsweise durchläuft eine typische OpenID Connect-konforme Webanwendung den /oauth/authorize-Endpunkt mit dem 'authorization code flow'.

  2. Wenn die Berechtigung erteilt wird, gibt der Autorisierungsserver ein Zugriffstoken an die Anwendung zurück.

  3. Die Anwendung verwendet das Zugriffstoken, um auf eine geschützte Ressource (wie eine API) zuzugreifen.

Während dieser Kommunikation wird der Inhalt des Tokens immer wieder lesbar über verschiedene Ressourcen hinweg übertragen.

NIEMALS Geheimnisse in einen unverschlüsselten Token packen!

5.1.1. OpenID Connect (OIDC)

https://de.wikipedia.org/wiki/OpenID_Connect

  • OpenID Connect (OIDC) ist ein Identitätsauthentifizierungsprotokoll, das eine Erweiterung der offenen Autorisierung (OAuth) 2.0 darstellt, um den Prozess der Authentifizierung und Autorisierung von Benutzern zu standardisieren, wenn sie sich anmelden, um auf digitale Dienste zuzugreifen.

  • Erweiterung von OAuth2

  • Wird gerne bei der Authentifizierung bei REST-Schnittstellen verwendet § Verwendet auch laut Spezifikation selbst REST-Schnittstellen und JSON-Datenformat

  • De-Fakto-Standard

5.1.2. Keycloak

https://en.wikipedia.org/wiki/Keycloak https://www.keycloak.org/ https://www.intension.de/infoblog/was-ist-keycloak/

  • Open Source

  • Implementierung von OpenID Connect und OAuth2 und SAML

    • LDAP, OAuth, SAML

  • Auf Java-Basis

  • Identity Access Management (IAM) System

  • On premise oder in Cloud

  • SAML - Im Java-Code mit Annotationen sagen, wer wo was darf

    • Muss ja auch im Code irgendwo definiert sein

    • Alt, aber immer noch OK

  • Single-Sign-On (SSO) Provider

ÜBUNG: https://quarkus.io/guides/security-jwt
Wenn wir uns nochmal die Claims (Anrechte) ins Gedächtnis rufen, dann gibt es GUI- und Server-bezogene. Wir bekommen jetzt am Server einen Bearer-Token im Authorization-Header und können den mit einer Library überprüfen (Signatur testen). Dann können wir am Backend Zugriff basierend auf diesen Claims zulassen oder nicht. Irgendwie müssen wir das dem Backend sagen (diese Rolle darf auf diesen Endpoint POST machen)… Das machen wir mit SmallryeJWT-Annotations.

6. Authorization Code Flow

https://developer.okta.com/docs/guides/implement-grant-type/authcode/main/

jwt 2

  1. Ihre Anwendung (App) fordert einen Autorisierungscode vom Autorisierungsserver (Okta) an.

  2. Okta präsentiert eine Authentifizierungsaufforderung (die Okta-Anmeldeseite) im Browser des Benutzers.

  3. Der Benutzer authentifiziert sich beim Autorisierungsserver und erteilt seine Zustimmung.

  4. Der Browser erhält nach der Benutzerauthentifizierung einen Autorisierungscode vom Autorisierungsserver (Okta). Der Autorisierungscode wird an Ihre App übergeben.

  5. Ihre App sendet diesen Code und das Client-Geheimnis an Okta. Siehe Austausch des Codes gegen Tokens.

  6. Okta gibt Zugriffs- und ID-Tokens zurück, sowie optional einen Aktualisierungstoken.

  7. Ihre App kann diese Tokens jetzt verwenden, um im Namen des Benutzers den Ressourcenserver (zum Beispiel eine API) aufzurufen.

  8. Der Ressourcenserver überprüft das Token, bevor er auf die Anfrage antwortet. Siehe Zugriffstoken validieren.

7. Access Token / Refresh Token

https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

7.1. Access Token

jwt 3

Hat traditionell eine sehr kurze Ablauffrist! Dadurch müssen die Clients sehr häufig am Authorization-Server einen neuen Access-Token abholen (aber eben nicht bei JEDEM Request). Wenn ich jetzt einen User sperren will (löschen oder die Rechte (Rollen) verändern), dann dauert es maximal genau diese Expires-Zeit, bis der Client einen neuen Token mit den neuen Rechten (oder keinen Token mehr) bekommt und damit diese Änderungen in Kraft treten.

7.2. Refresh Token

Verhindert, dass Du immer wieder Dein Passwort am Google-OAuth-Authorization Server eingeben musst. Client muss trotzdem zum Authorization-Server. Falls Änderungen in der Berechtigung waren, werden diese im neuen Access-Token mitgegeben. Wenn der User gelöscht wurde, bekommt er auch mit dem Refresh-Token keinen neuen Access-Token mehr.

jwt 4