Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Connect

1. qaware.de Anwendungsübergreifende Authentiﬁzierung: 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 Authentiﬁzierung ■ 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 deﬁniert – 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 Veriﬁer 5. Access Token Grant + Code Veriﬁer

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 ■ Identiﬁziert 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 identiﬁziert ■ Alternativ per Access-Token (JWT oder Opaque mit Introspection) ■ Oft per Konﬁguration 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 Authentiﬁzierungen (z.B. Client-Zertiﬁkate) 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 identiﬁziert ■ Alternativ per Access-Token (JWT oder Opaque mit Introspection) (für REST Services) ■ Oft per Konﬁguration 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 Authentiﬁzierungen (z.B. Client-Zertiﬁkate) 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 deﬁniert 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 – Pﬂicht – 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

Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Connect

Du liest eine Vorschau.

Hier ansehen

Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Connect

Weitere Verwandte Inhalte

Ähnlich wie Anwendungsübergreifende Authentifizierung: Integrations-Pattern für OpenID Connect (20)

Weitere von QAware GmbH (20)

Aktuellste (20)