qaware.de
Integrations-Pattern für OpenID
Connect
Christian Fritz
christian.fritz@qaware.de
@chrfritz

QAware | 2

Inhalt
1. Einführung
2. Static & Server Side Rendered UI
3. Single Page Applications
4. Fat Clients & Mobile Applications
5. Outgoing Backend Requests

OAuth 2 ist ein Protokoll für delegierte Autorisierung mit
Web Technologien
QAware | 4
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

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 | 5

Weitere Features von OIDC
QAware | 6
■ 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

OIDC Synonyme für OAuth 2 Elemente
QAware | 7
OpenID Connect OAuth 2
OpenID Provider (OP) Authorization Server
Relying Party (RP) Client application

User Agent
Authorization Code Flow with PKCE
QAware | 8
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

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 | 9

Token in OAuth 2 und OpenID Connect
QAware | 10
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

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

Static & Server Side Rendered UI

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

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

Proxy vor der Anwendung
QAware | 15
Vorteile:
■ Einfach
■ Keine bis wenige Änderungen an der
Anwendung notwendig
■ Oft kompatibel zu bestehenden Systemen
■ Kann Zentral gemanaged werden
Nachteile:
■ 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

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

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

OIDC direkt in die Anwendung integrieren
QAware | 18
Vorteile:
■ 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
Nachteile:
■ Potentiell umfangreiche Anpassungen in der
Anwendung
■ Höherer Implementierungsaufwand
■ Potentiell unbekannte Sicherheitsrisiken durch
eigene Implementierung

Single Page Applications

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

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

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

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

Single Page Application ohne Backend
QAware | 24
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)

Fat Clients & Mobile Applications

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

Fat Clients & Mobile Applications - Callback Varianten
QAware | 27
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

Fat Clients & Mobile Applications - Callback Varianten
QAware | 28
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

Fat Clients & Mobile Applications - Callback Varianten
QAware | 29
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

Outgoing Backend Requests

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

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

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

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

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

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 | 36
{
"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 :

Token-Exchange
QAware | 37
Vorteile:
■ Hohes Sicherheitsniveau
■ Vermeidet Confused Deputy Problem
■ Resource-Server kann genauere
Autorisierung anhand Person und beteiligter
Services durchführen
Nachteile:
■ 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

Links
QAware | 38
■ 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-09 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

Q&A

Lerne uns bei einem online Schreibtisch-Workout kennen
Meistens fängt man ja erst an, wenn‘s schon zwickt.
Damit das gar nicht erst passiert, zeigt uns eine Trainerin von
Besser Bewegen Übungen, die man in einer kleinen Pause am
Schreibtisch machen kann, um die Rückenmuskulatur gezielt zu
stärken, Schmerzen vorzubeugen oder zu lindern.
Fr, 01.07. 12:45-13:30
Di, 19.07. 12:45-13:30
Anmeldung an susanna.suchan@qaware.de
&