JUG Meetup Nürnberg, Oktober 2022,(Christian Fritz, @chrfritz, Senior Software Engineer @QAware) == Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! == OAuth2 und OpenID Connect (OIDC) sind ausgereifte Standards zur Authentifizierung und Autorisierung. Der Zugriff auf OIDC-geschütze Services ist schnell gebaut: Das Token über eine Lib holen, das dann in den "Authorization"-Header … und fertig. Doch das ist nur die halbe Miete. Was ist mit: -dem Legacy Client dessen Backend auf einmal mit OIDC geschützt wird? -dem Backend for Frontend, das von einer Single Page Applikation genutzt werden soll? -dem Service, der einen weiteren OIDC geschützten Service abfragen muss? Für diese und viele Integrationen gibt es offensichtlich nicht "die eine Lösung". Der Talk zeigt kurz die Grundlagen von OIDC und mögliche Integrations-Pattern für verschiedene Ausgangslagen.

1. qaware.de
Anwendungsübergreifende
Authentifizierung:
Integrations-Pattern für OpenID
Connect
Christian Fritz
christian.fritz@qaware.de
@chrfritz

2. QAware | 2
Christian Fritz
Senior Software Engineer
@chrfritz
#cloudnativenerd
#qaware #gernperDude

3. OAuth 2 ist ein Protokoll für delegierte Autorisierung mit
Web Technologien
QAware | 3
Client
Resource
Owner
Authorization
Server
Resource
Server
5. Access Token
6. Protected Resource
3. Authorization Grant
4. Access Token
1. Authorization Request
2. Authorization Grant

4. OpenID Connect erweitert OAuth 2 um Authentifizierung
■ Erlaubt die Prüfung der Identität des Anwenders
■ dazu liefert der Token-Endpoint ein weiteres Token: Das ID Token
■ ID Token: JWT, welches grundlegende Informationen über den Anwender
enthält
– Felder im Payload, sog. Claims, im Standard definiert
– u.A. Aussteller, Antragsteller, Subjekt (typ. User ID), Gültigkeit (Service
Endpunkte, Zeitraum)
■ User Info Endpunkt um erweiterte Informationen über den Anwender
abzurufen
QAware | 4

5. Weitere Features von OIDC
QAware | 5
■ Auffinden aller notwendigen Endpunkte
– Authorize Endpoint
– Token Endpoint
– User Info Endpoint
– JWKS Endpoint
■ JSON Web Key Set Endpunkt um Signatur Keys für JWTs abzufragen
■ Erweiterbar

6. User Agent
Authorization Code Flow with PKCE
QAware | 6
Resource
Owner
Client
Authorization
Server
Erzeugen eines
Code Verifier
und berechnen
der Code
Challenge
1. Authorization Request + Code Challenge
2. Authorization
3. Authorization Code Grant + Code Challenge
4. Access Token Request + Code Verifier
5. Access Token Grant + Code Verifier

7. Authorization Code
■ Code welcher beim Token-Endpunkt gegen ein Access Token eingetauscht werden kann
■ Nur einmalig Gültig
Access Token
■ Erlaubt den Zugriff auf Ressourcen welche von einem Resource Server bereit gestellt werden
■ Ersatz für verschiedene andere Authorisierungs-Mechanisem wie Benutzername & Passwort
■ Darf beliebiger String sein solange er folgender Vorgabe entspricht:
1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
■ Meist kurze Gültigkeit (wenige Minuten)
■ Daher muss kein JWT sein
Token in OAuth 2 und OpenID Connect
QAware | 7

8. Token in OAuth 2 und OpenID Connect
QAware | 8
Refresh Token
■ Erlaubt ein abgelaufenes Access Token zu erneuern
■ Üblicherweise ein zufälliger String
■ Keine Ausweitung der bisherigen Berechtigungen möglich, weitere Einschränkung schon
■ Sollte nach einmaliger Nutzung ungültig werden
■ Lange Gültigkeit ohne Nutzung (Tage bis Monate)
ID Token
■ Immer ein JWT
■ Beinhaltet immer Aussteller, Subjekt und Gültigkeit (Services & Zeit)
■ Weitere Felder möglich
■ Signiert und kann meist gegen JWKS validiert werden

9. Die Anwendungslandschaft
QAware | 9
JSF Monolith
Vertrags-
daten
Single Page App
Legacy VB.Net
Client
Kunden-
daten
Kundendaten
Service
Vertragsdaten
Service
1
2
4
3
Sachbearbeiter
Kunde

10. Static & Server Side Rendered UI

11. Proxy vor der Anwendung
QAware | 11
OAuth 2 Proxy Anwendung
■ Führt den jeweiligen OAuth2 Flow (z.B. Authorization Code) durch
■ Identifiziert den Client durch Cookies
– Alternativ falls erlaubt, auch per JWT
■ Leitet ggf. User Informationen an die Anwendung weiter
OIDC Provider

12. Proxy vor der Anwendung - Alternative
QAware | 12
Standard Reverse
Proxy (z.B. Nginx)
Anwendung
OAuth 2 Proxy
Authorization
Request
Response 202
oder 401
■ Wird vom Reverse Proxy mit allen vom
Client gesendeten Headern angefragt
■ Gibt entweder 202 Accepted oder 401
Unauthorized zurück
OIDC Provider

13. Nachteile:
Proxy vor der Anwendung
QAware | 13
Vorteile:
■ Einfach
■ Keine bis wenige Änderungen an der
Anwendung notwendig
■ Oft kompatibel zu bestehenden Systemen
■ Kann Zentral gemanaged werden
■ mind. ein zusätzlicher Hop (erhöht die Latenz)
■ Weitergabe von Nutzerinformationen
problematisch
■ (noch) keine Standard-Header um
Nutzerdaten an Anwendung weiterzuleiten
■ Keine End2End Verschlüsselung zwischen
Client und Anwendung

14. Proxy vor der Anwendung - Sicherheitsaspekte
QAware | 14
■ Schutz der Header mit Nutzerinformationen
– Müssen vom OAuth 2 Proxy gesetzt/gelöscht werden
OAuth 2 Proxy Anwendung
��
■ Die Anwendung darf nur über den Proxy erreichbar sein. (z.B. per Sidecar
Deployment)

15. OIDC direkt in die Anwendung integrieren
QAware | 15
Anwendung
■ Anwendung implementiert den Authorization Code Flow selbst
■ Nutzer wird per Session-Cookie identifiziert
■ Alternativ per Access-Token (JWT oder Opaque mit Introspection)
■ Oft per Konfiguration im Anwendungsframework aktivierbar (z.B. in Spring Boot)
OIDC Provider

16. Nachteile:
Vorteile:
OIDC direkt in die Anwendung integrieren
QAware | 16
■ Weniger Hops und damit Latenz
■ Einfacher Zugriff auf Nutzerinformationen
■ End2End Verschlüsselung zwischen Client und
Anwendung möglich
■ Fertige Bibliotheken für die Implementierung
der Flows
■ Unterstützung weiterer Authentifizierungen
(z.B. Client-Zertifikate) möglich
■ Potentiell umfangreiche Anpassungen in der
Anwendung
■ Höherer Implementierungsaufwand
■ Potentiell unbekannte Sicherheitsrisiken durch
eigene Implementierung

17. Single Page Applications

18. Single Page Application mit Backend
QAware | 18
Backend for
Frontend
OIDC Provider
(Authorization & Token Endpoint)
Browser mit SPA
■ Wie zuvor bei der direkten Integration von OIDC in die Anwendung
■ Backend Anwendung implementiert den Authorization Code Flow selbst
■ Nutzer wird per Session-Cookie identifiziert
■ Alternativ per Access-Token (JWT oder Opaque mit Introspection) (für REST
Services)
■ Oft per Konfiguration im Anwendungsframework aktivierbar (z.B. in Spring
Boot)
Anwendung /
Andere Backends

19. Vorteile:
OIDC direkt in die Anwendung integrieren - Vorteile
QAware | 19
■ Einfacher Zugriff auf Nutzerinformationen
innerhalb der Anwendung
■ End2End Verschlüsselung zwischen Client und
Anwendung möglich
■ Fertige Bibliotheken für die Implementierung
der Flows
■ Unterstützung weiterer Authentifizierungen
(z.B. Client-Zertifikate) möglich
■ Kein Token Handling in der SPA notwendig
■ Höheres Sicherheitsniveau des OIDC Clients
→ Je nach Information Security Lage, zugriff
auf sensiblere Nutzerinformationen möglich
■ Backend-for-Frontend möglich

20. Nachteile:
OIDC direkt in die Anwendung integrieren - Nachteile
QAware | 20
■ Potentiell umfangreiche Anpassungen in der
Anwendung
■ Höherer Implementierungsaufwand
■ Potentiell unbekannte Sicherheitsrisiken durch
eigene Implementierung
■ SPA und Backend eng gekoppelt
■ Same Origin von SPA und Backend notwendig
■ Login & Session-Timeout erfordern Browser
Redirect und Neuladen der Seite

21. Single Page Application ohne Backend
QAware | 21
Resource Server
OIDC Provider
Browser mit SPA
Resource Server
■ SPA führt Authorization Code Flow with PKCE durch
■ Resource Server erwarten nur Access-Token und ggf. ID Token

22. Nachteile:
Vorteile:
Single Page Application ohne Backend
QAware | 22
■ Lose Koppelung zwischen Frontend und
Backends
■ WebComponents mit verschiedenen
Backends möglich
■ Flow und Token Handling in der SPA
notwendig
– Authorization Code Flow with PKCE
notwendig
– Token Refresh muss in der SPA
regelmäßig durchgeführt werden
■ Niedrigeres Sicherheitsniveau des Clients
→ möglicherweise kein Zugriff auf sensible
Nutzerdaten (Regulatorik)
■ Cross-Origin Resource Sharing (CORS)

23. Fat Clients & Mobile Applications

24. Fat Client & Mobile Applications - Authorization Code Flow
with PKCE
QAware | 24
Resource Server
Browser
OIDC Provider -
Authorize Endpoint
Fat Client
/
Mobile Application
Callback
Behandlung
OIDC Provider -
Token Endpoint

25. Fat Clients & Mobile Applications - Callback Varianten
QAware | 25
Lokaler Webserver:
■ OS Unabhängig
■ Relativ einfach
■ Ports müssen vorab definiert werden
■ Ports können belegt sein
■ Firewall Probleme möglich für Dienste auf Localhost; Port > 1024

26. Fat Clients & Mobile Applications - Callback Varianten
QAware | 26
Private use URI Scheme
com.example.app:/oauth2redirect/example-provider
■ OS Abhängig
■ Muss im Betriebssystem registriert werden
■ Müssen eindeutig für jede Anwendung sein
■ Kein lokaler Webserver notwendig
■ Startet möglicherweise die Anwendung ein zweites mal

27. Fat Clients & Mobile Applications - Callback Varianten
QAware | 27
Registrierte HTTPS Redirection
https://app.example.com/oauth2redirect/example-provider
■ OS Abhängig
■ Muss im Betriebssystem registriert werden
■ Identität des Clients wird durch das Betriebssystem garantiert
■ Müssen eindeutig für jede Anwendung sein
■ Kein lokaler Webserver notwendig
■ Startet möglicherweise die Anwendung ein zweites mal

28. Demo Time

29. Outgoing Backend Requests

30. Besonders geschützte Backends
QAware | 30
JSF Monolith
Vertrags-
daten
Single Page App
Legacy VB.Net
Client
Kunden-
daten
Kundendaten
Service
Vertragsdaten
Service
1
2
4
3
Kunde
Sachbearbeiter

31. Besonders geschützte Backends
QAware | 31
Single Page App
Legacy VB.Net
Client
Kunden-
daten
Kundendaten
Service
Vertragsdaten
Service
Kunde
Sachbearbeiter
��🏽💻
��
��
��
��🏽💻
��

32. Besonders geschützte Backends
QAware | 32
Single Page App
Legacy VB.Net
Client
Kunden-
daten
Kundendaten
Service
Vertragsdaten
Service
Kunde
Sachbearbeiter
��🏽💻
��
��
��
��
��

33. Besonders geschützte Backends
QAware | 33
Single Page App
Legacy VB.Net
Client
Kunden-
daten
Kundendaten
Service
Vertragsdaten
Service
Kunde
Sachbearbeiter
��🏽💻
��
��
��🏽💻
��🏽💻
��

34. Token-Exchange im Detail
QAware | 34
(Start) Resource
Server
OIDC Provider
(Authorization & Token Endpoint)
Browser mit SPA
■ Start Resource Server muss sich eigenes Token per Client Credentials Flow holen
■ Start Resource Server tauscht erhaltens Token zusammen mit eigenem Token gegen
ein neues kombiniertes Token
■ Kombiniertes Token dient dann zum Zugriff auf Ziel Resource Server
(Ziel) Resource
Server
AuthCode Flow with
PKCE
Token-Exchange Flow

35. Token-Exchange
Request (Auszug):
■ Grant Type:
urn:ietf:params:oauth:grant-type:token-
exchange
■ Subject Token
– Pflicht
– Token des Nutzers im Namen dessen der
Request durchgeführt wird
■ Actor Token
– Optional
– Token des Services welcher den Request
tatsächlich durchführt
QAware | 35
{
"aud":"https://service26.example.com",
"iss":"https://issuer.example.com",
"exp":1443904100,
"nbf":1443904000,
"sub":"user@example.com",
"act":
{
"sub":"https://service16.example.com",
"act":
{
"sub":"https://service77.example.com"
}
}
}
Claims im Kombinierten Token :

36. Nachteile:
Vorteile:
Token-Exchange
QAware | 36
■ Hohes Sicherheitsniveau
■ Vermeidet Confused Deputy Problem
■ Resource-Server kann genauere
Autorisierung anhand Person und beteiligter
Services durchführen
■ Tokentausch erhöht Latenz der gesamten
Aufrufkette
■ Aufwand der Implementierung
■ Caching sensibler Daten notwendig &
gleichzeitig nicht immer erlaubt
■ Neuer Grant Type am Token-Endpunkt noch
nicht bei jedem OIDC Provider verfügbar

37. Links
QAware | 37
■ RFC 6749 The OAuth 2.0 Authorization Framework
■ OpenID Connect Core 1.0
■ RFC 6750 OAuth 2.0 Authorization Framework: Bearer Token Usage
■ draft-ietf-oauth-browser-based-apps OAuth 2.0 for Browser-Based Apps
■ RFC 8252 OAuth 2.0 for Native Apps
■ RFC 8693 OAuth 2.0 Token Exchange
■ draft-ietf-oauth-security-topics-19 OAuth 2.0 Security Best Current Practice

38. Q&A