OAuth 2.0

126. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Wie ich lernte RFCs zu mögen

MARTIN FUNK
Zur Person
Studium: Diplom Mathematiker RWTH-
Aachen
Beruf: Freiberufler
Erstcomputer: C64
Martin Funk
(1983)

MARTIN FUNK
OAuth 2.0
Was ist das denn genau?
https://tools.ietf.org/html/rfc6749

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)

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

MARTIN FUNK
OAuth 2.0
Ein Authorisierungskonzept für verteilte Applikationen

MARTIN FUNK
Authorisierungskonzept für eine Applikation
(Client/Server)

MARTIN FUNK
Basic Authentication
Client
Resource-
Server
HTTP Request
HTTP Response
>GET /manager/html HTTP/1.1
>Host: localhost:8080
>Authorization: Basic dG9tZWU6dG9tZWU=
Base64(username+password)

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

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

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

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

MARTIN FUNK
(a) Client Authentication
(b) Access Token
Client Authorization
Server
Access Token
HTTP 200 OK
Resource
Server

MARTIN FUNK
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 ✅

MARTIN FUNK
(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

MARTIN FUNK
1. Resource Owner != Client ✅
2. Zugangsberechtigung eingeschränkt übertragen ❌
3. Client speichert Zugangskennung nicht ✅ ❓
4. Zugangsberechtigung lässt sich zurückziehen ✅ ❓

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)

MARTIN FUNK
3. Implicit Grant
2. Zugangsberechtigung eingeschränkt übertragen ✅
3. Client speichert Zugangskennung nicht ✅
4. Zugangsberechtigung lässt sich zurückziehen ✅

MARTIN FUNK
(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

MARTIN FUNK
2. Zugangsberechtigung eingeschränkt übertragen ✅
3. Client speichert Zugangskennung nicht ✅
4. Zugangsberechtigung lässt sich zurückziehen ✅

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

MARTIN FUNK
Zielbild:
1. JSON Web Token (JWT)
R-ServerAT
AT
AT
AT
AT AT
AT
JSON Web Token to the rescue!
Client
Auth-
Server

MARTIN FUNK
 Header
{"alg": "HS256", "typ": "JWT"}
 Payload
{"iss":"joe", "exp":1300819380,
"http://example.com/is_root":true}
>GET /manager/html HTTP/1.1
>Host: localhost:8080
>Authorization: Bearer eyJhbGciOiJIUzI1Ni
IsInR5cCI6IkpXVCJ9.eyJpc3MiOiJqb2UiLCJleH
AiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmN
vbS9pc19yb290Ijp0cnVlfQ.N_itXQGXQiAVREinp
qu-YHuCq4P2Gp5dIP9cp3vsVcA
JSON Web Token (JWT)
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzO
DAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb2
90Ijp0cnVlfQ.N_itXQGXQiAVREinpqu-
YHuCq4P2Gp5dIP9cp3vsVcA ‫٭‬https://jwt.io/
 Base64(header “.“ payload “.“ sign(header,
payload))

MARTIN FUNK
Finale?
Client
Auth
Server
Resource
Server
☀️
🌧 🌧
🌧 🌧

MARTIN FUNK
Was aber wenn?
Client
Auth
Server
Resource
Server
⛈
Verkaufe 50 💎
bei 200 💰
Verkaufe 50 💎 Verkauft 5 💎
z.B.: Handelsplattform

MARTIN FUNK
>POST /foo HTTP/1.1
>Host: example.org
>Date: Tue, 07 Jun 2014 20:51:35 GMT
>Content-Type: application/json
>Content-Length: 18
{"hello": "world"}
Signing HTTP Messages
https://tools.ietf.org/html/draft-cavage-http-signatures-10
>POST /foo HTTP/1.1
>Host: example.org
>Date: Tue, 07 Jun 2014 20:51:35 GMT
>Content-Type: application/json
>Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWD...
>Signature: keyId="Test",algorithm="rsa-sha256",
headers="(request-target) host date content-type
digest content-length", signature="vSdrb+dS3Ec
eC9bcwHSo4MlyKS59iFIr....“
>Content-Length: 18
{"hello": "world"}

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

MARTIN FUNK
IETF Meetings
• IETF 103 Bangkok, 3. November 2018 – 9. November 2018
• IETF 104 Prag, 23. März 2019 – 29. März 2019

MARTIN FUNK
„Anyone can invent a security system that
he himself cannot break“
*Schneier‘s Law

MARTIN FUNK
Noch Fragen?
E-Mail: Martin@MartinFunk.de
Xing: https://www.xing.com/profile/Martin_Funk
Twitter: @funkattack
Martin Funk

MARTIN FUNK
Links 1:
1. Basic Authentication
• https://tools.ietf.org/html/rfc2617
2. The OAuth 2.0 Authorization Framework
3. JSON Web Token (JWT)
4. Signing HTTP Messages
• https://tools.ietf.org/html/draft-cavage-http-signatures-09
5. OAuth 2.0 Threat Model and Security Considerations

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

OAuth 2.0

Recommandé

Recommandé

Contenu connexe

Similaire à OAuth 2.0

Similaire à OAuth 2.0 (13)

OAuth 2.0

Notes de l'éditeur