1. 126. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Wie ich lernte RFCs zu mögen
2. 226. September 2018 @funkattack
MARTIN FUNK
Zur Person
Studium: Diplom Mathematiker RWTH-
Aachen
Beruf: Freiberufler
Erstcomputer: C64
Martin Funk
(1983)
3. 326. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Was ist das denn genau?
https://tools.ietf.org/html/rfc6749
4. 426. September 2018 @funkattack
MARTIN FUNK
IETF
Internet Engineering Task Force
1. offene, internationale Freiwilligenvereinigung
2. steht jedem interessierten Individuum offen
3. besitzt als lose Organisation keine Rechtsform
4. existiert seit Januar 1986
5. trifft sich vierteljährlich (weltweit)
6. “Hütet“ RFCs (gut 8000)
5. 526. September 2018 @funkattack
MARTIN FUNK
RFCs
Request for Comments
Hypertext Transfer Protocol 1.0 / 1.1 /2.0
rfc1945, rfc2616, rfc7540
MUST, MUST NOT, SHOULD, SHOULD NOT, MAY
rfc2119
Defining the IETF
rfc3233
On Consensus and Humming in the IETF
rfc7282
6. 626. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Ein Authorisierungskonzept für verteilte Applikationen
7. 726. September 2018 @funkattack
MARTIN FUNK
Authorisierungskonzept für eine Applikation
(Client/Server)
8. 826. September 2018 @funkattack
MARTIN FUNK
Basic Authentication
https://tools.ietf.org/html/rfc2617
Client
Resource-
Server
HTTP Request
HTTP Response
>GET /manager/html HTTP/1.1
>Host: localhost:8080
>Authorization: Basic dG9tZWU6dG9tZWU=
Base64(username+password)
9. 926. September 2018 @funkattack
MARTIN FUNK
Basic Authentication (Kritik)
Client
Resource-
Server
HTTP Request
HTTP Response
1. Resource Owner == Client
2. Zugangsberechtigung wird uneingeschränkt
übertragen
3. Client speichert Zugangskennung
4. Zugangsberechtigung lässt sich nicht
zurückziehen
5. Server muss Zugangskennung
authentisieren
6. Zugangskennung in jedem Aufruf
10. 1026. September 2018 @funkattack
MARTIN FUNK
The OAuth 2.0 Authorization Framework
1. Resource Owner != Client
2. Zugangsberechtigung uneingeschränkt übertragen
3. Client speichert Zugangskennung nicht
4. Zugangsberechtigung lässt sich nicht zurückziehen
5. Server muss Zugangskennung nicht authentisieren
6. Zugangskennung nicht in jedem Aufruf
https://tools.ietf.org/html/rfc6749
11. 1126. September 2018 @funkattack
MARTIN FUNK
Rollen Modell von OAuth 2.0
Client
Authorization
Server
Resource
Server
(a) Owner Credentials
(b) Authorization Code
(c) Access Token
(d) Refresh Token
User
Agent
Owner
12. 1226. September 2018 @funkattack
MARTIN FUNK
Ablauf-Modelle von OAuth 2.0
1. Client Credentials Grant
2. Resource Owner Password Credentials Grant
3. Implicit Grant
4. Authorization Code Grant
13. 1326. September 2018 @funkattack
MARTIN FUNK
1. Client Credentials Grant
(a) Client Authentication
(b) Access Token
Client Authorization
Server
Access Token
HTTP 200 OK
Resource
Server
14. 1426. September 2018 @funkattack
MARTIN FUNK
1. Client Credentials Grant
1. Resource Owner != Client ❌
2. Zugangsberechtigung eingeschränkt übertragen ❌
3. Client speichert Zugangskennung nicht ❌
4. Zugangsberechtigung lässt sich zurückziehen ❌
5. Server muss Zugangskennung nicht authentisieren ✅
6. Zugangskennung nicht in jedem Aufruf ✅
15. 1526. September 2018 @funkattack
MARTIN FUNK
2. Resource Owner Password Credentials Grant
(a) Resource Owner Password Credentials
Client
(b) Resource Owner Password Credentials
(c) Access Token (w/ Optional Refresh Token)
Authorization
Server
Access Token
HTTP 200 OK
Resource
Server
Refresh Token
16. 1626. September 2018 @funkattack
MARTIN FUNK
2. Resource Owner Password Credentials Grant
1. Resource Owner != Client ✅
2. Zugangsberechtigung eingeschränkt übertragen ❌
3. Client speichert Zugangskennung nicht ✅ ❓
4. Zugangsberechtigung lässt sich zurückziehen ✅ ❓
5. Server muss Zugangskennung nicht authentisieren ✅
6. Zugangskennung nicht in jedem Aufruf ✅
17. 1726. September 2018 @funkattack
MARTIN FUNK
3. Implicit Grant
USER
AGENT
(b)
CLIENT
(a)
AUTHORIZATION
SERVER
WEB-HOSTED
CLIENT
RESOURCE
(a) Client Identifier and Redirection URI
(b) User authenticates
(c) Redirection URI with Access Token in Fragment
(d) Redirection URI without Fragment
(e) Script
(g) Access Token
Owner
Access Token
HTTP 200 OK
Browser <-> Webapplikation
(f)
18. 1826. September 2018 @funkattack
MARTIN FUNK
3. Implicit Grant
1. Resource Owner != Client ✅
2. Zugangsberechtigung eingeschränkt übertragen ✅
3. Client speichert Zugangskennung nicht ✅
4. Zugangsberechtigung lässt sich zurückziehen ✅
5. Server muss Zugangskennung nicht authentisieren ✅
6. Zugangskennung nicht in jedem Aufruf ✅
19. 1926. September 2018 @funkattack
MARTIN FUNK
4. Authorization Code Grant
(b)
USER
AGENT
CLIENT
(a) (c)
(a) Client Identifier and Redirection URI
(b) User authenticates
(c) Authorization Code
AUTHORIZATION
SERVER
(d) Authorization Code and Redirection URI
(e) Access Token (w/ Optional Refresh Token)
Owner
Access Token
HTTP 200 OK
Resource
Server
20. 2026. September 2018 @funkattack
MARTIN FUNK
4. Authorization Code Grant
1. Resource Owner != Client ✅
2. Zugangsberechtigung eingeschränkt übertragen ✅
3. Client speichert Zugangskennung nicht ✅
4. Zugangsberechtigung lässt sich zurückziehen ✅
5. Server muss Zugangskennung nicht authentisieren ✅
6. Zugangskennung nicht in jedem Aufruf ✅
21. 2126. September 2018 @funkattack
MARTIN FUNK
Alle Häckchen grün!
1. Token im RFC nicht näher spezifiziert
2. AS könnte Token bestätigen
3. Microservices?
4. Unauthorisiertes Backend?
5. Authorisierung durch Auth-Server?
Was aber ist mit den Token?
Auth-
Server
R-ServerAT
AT
AT
AT
AT AT
AT
Client
22. 2226. September 2018 @funkattack
MARTIN FUNK
Zielbild:
1. JSON Web Token (JWT)
https://tools.ietf.org/html/rfc7519
R-ServerAT
AT
AT
AT
AT AT
AT
JSON Web Token to the rescue!
Client
Auth-
Server
24. 2426. September 2018 @funkattack
MARTIN FUNK
Finale?
Client
Auth
Server
Resource
Server
☀️
🌧 🌧
🌧 🌧
25. 2526. September 2018 @funkattack
MARTIN FUNK
Was aber wenn?
Client
Auth
Server
Resource
Server
⛈
Verkaufe 50 💎
bei 200 💰
Verkaufe 50 💎 Verkauft 5 💎
z.B.: Handelsplattform
27. 2726. September 2018 @funkattack
MARTIN FUNK
Resümee, für Entwickler
1. Sicherheit ist ultra schwierg
Allein im Oauth Umfeld eine Vielzahl von RFCs
2. Keine grüne Wiese Projekte zu erwarten
3. Bestehende Infrastruktur nutzen / andocken
4. Rolle der Clients ist unterschätzt
5. Bei Neuimplementierungen rfc6819 beachten
OAuth 2.0 Threat Model and Security Considerations
28. 2826. September 2018 @funkattack
MARTIN FUNK
IETF Meetings
• IETF 103 Bangkok, 3. November 2018 – 9. November 2018
• IETF 104 Prag, 23. März 2019 – 29. März 2019
29. 2926. September 2018 @funkattack
MARTIN FUNK
„Anyone can invent a security system that
he himself cannot break“
*Schneier‘s Law
30. 3026. September 2018 @funkattack
MARTIN FUNK
Noch Fragen?
E-Mail: Martin@MartinFunk.de
Xing: https://www.xing.com/profile/Martin_Funk
Twitter: @funkattack
Martin Funk
31. 3126. September 2018 @funkattack
MARTIN FUNK
Links 1:
1. Basic Authentication
• https://tools.ietf.org/html/rfc2617
2. The OAuth 2.0 Authorization Framework
• https://tools.ietf.org/html/rfc6749
3. JSON Web Token (JWT)
• https://tools.ietf.org/html/rfc7519
4. Signing HTTP Messages
• https://tools.ietf.org/html/draft-cavage-http-signatures-09
5. OAuth 2.0 Threat Model and Security Considerations
• https://tools.ietf.org/html/rfc6819
32. 3226. September 2018 @funkattack
MARTIN FUNK
Links 2:
1. Quelle von IETF_Logo.svg
• https://www.ietf.org/static/img/ietf-logo.e4b6ca0dd271.gif
2. Schneiers Law
• https://www.schneier.com/blog/archives/2011/04/schneiers_law.html
Notes de l'éditeur
Labormodell Ausgangsmodell
Das ist natürlich nicht ganz fair, aber im Kern richtig.
Was passiert hier:
Das ist natürlich nicht ganz fair, aber im Kern richtig.
Was passiert hier:
Das ist natürlich nicht ganz fair, aber im Kern richtig.
Was passiert hier:
Das ist natürlich nicht ganz fair, aber im Kern richtig.
Was passiert hier: