CloudLand 2023, Juni 2023, Christian Fritz (Senior Software Engineer bei QAware) Wenn Benutzer und Services authentifiziert werden sollen, kommt immer öfter OpenID Connect (OIDC) zum Einsatz. Im einfachsten Fall reicht es schon, das eingesetzte Framework richtig zu konfigurieren. Dann spricht die UI mit einem OIDC-geschützen Backend. Oder man schützt einen Service und authentifiziert mit OIDC die Benutzer. Doch meistens gibt es nicht nur ein einziges Integrationsszenario.In diesem Workshop setzen wir an einer Single Page App, einem Backend-Service und einer Mobile bzw. Desktop App die möglichen Integrationsszenarien um und lernen so die Vor- und Nachteile der Szenarien kennen. Zum Abschluss probieren wir, den Zugriff auf den API-Server eines Kubernetes Cluster mittels OIDC zu schützen und zu personalisieren. Voraussetzungen: Laufendes Kubernetes (vorzugsweise Minikube) inkl. kubectl, Git, Helm, ggf. Flux CD.

1. qaware.de
Security Lab: OIDC in der Praxis
Christian Fritz - Software Architect
christian.fritz@qaware.de
@chrfritz@chaos.social

2. QAware | 2

3. https://github.com/chr-fritz/security-
lab-oidc-integrations

4. Proxy vor der Anwendung
QAware | 4
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

5. Proxy vor der Anwendung - Alternative
QAware | 5
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

6. Proxy vor der Anwendung - Sicherheitsaspekte
QAware | 6
■ 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)

7. OIDC direkt in die Anwendung integrieren
QAware | 7
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

8. Single Page Applications

9. Single Page Application mit Backend
QAware | 9
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

10. OIDC direkt in die Anwendung integrieren - Vorteile
QAware | 10
Vorteile:
■ 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
■ 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

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

12. Single Page Application ohne Backend
QAware | 12
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

13. Single Page Application ohne Backend
QAware | 13
Vorteile:
■ Lose Koppelung zwischen Frontend und
Backends
■ WebComponents mit verschiedenen
Backends möglich
Nachteile:
■ 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)

14. Fat Clients & Mobile Applications

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

16. Outgoing Backend Requests

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

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

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

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

21. Token-Exchange im Detail
QAware | 21
(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