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

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

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

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

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

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

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

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

Single Page Applications

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

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

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

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

Nachteile:
Vorteile:
Single Page Application ohne Backend
QAware | 23
■ 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)

Fat Clients & Mobile Applications

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

Fat Clients & Mobile Applications - Callback Varianten
QAware | 26
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 | 27
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 | 28
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 | 30
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 | 31
Single Page App
Legacy VB.Net
Client
Kunden-
daten
Kundendaten
Service
Vertragsdaten
Service
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
��🏽💻
��
��
��🏽💻
��🏽💻
��

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

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 :

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

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

Q&A