SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Downloaden Sie, um offline zu lesen
126. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Wie ich lernte RFCs zu mögen
226. September 2018 @funkattack
MARTIN FUNK
Zur Person
Studium: Diplom Mathematiker RWTH-
Aachen
Beruf: Freiberufler
Erstcomputer: C64
Martin Funk
(1983)
326. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Was ist das denn genau?
https://tools.ietf.org/html/rfc6749
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)
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
626. September 2018 @funkattack
MARTIN FUNK
OAuth 2.0
Ein Authorisierungskonzept für verteilte Applikationen
726. September 2018 @funkattack
MARTIN FUNK
Authorisierungskonzept für eine Applikation
(Client/Server)
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)
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
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
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
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
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
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 ✅
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
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 ✅
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)
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 ✅
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
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 ✅
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
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
2326. September 2018 @funkattack
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)
https://tools.ietf.org/html/rfc7519
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzO
DAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb2
90Ijp0cnVlfQ.N_itXQGXQiAVREinpqu-
YHuCq4P2Gp5dIP9cp3vsVcA ‫٭‬https://jwt.io/
 Base64(header “.“ payload “.“ sign(header,
payload))
2426. September 2018 @funkattack
MARTIN FUNK
Finale?
Client
Auth
Server
Resource
Server
☀️
🌧 🌧
🌧 🌧
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
2626. September 2018 @funkattack
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"}
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
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
2926. September 2018 @funkattack
MARTIN FUNK
„Anyone can invent a security system that
he himself cannot break“
*Schneier‘s Law
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
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
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

Weitere ähnliche Inhalte

Ähnlich wie OAuth 2.0

Datenbasierte Services mit Entity Framework und Co.
Datenbasierte Services mit Entity Framework und Co.	Datenbasierte Services mit Entity Framework und Co.
Datenbasierte Services mit Entity Framework und Co. Manfred Steyer
 
Datengetriebene Web APIs mit Entity Framework
Datengetriebene Web APIs mit Entity FrameworkDatengetriebene Web APIs mit Entity Framework
Datengetriebene Web APIs mit Entity FrameworkManfred Steyer
 
PageSpeed Extreme für das große Speed Update 2021
PageSpeed Extreme für das große Speed Update 2021PageSpeed Extreme für das große Speed Update 2021
PageSpeed Extreme für das große Speed Update 2021SEARCH ONE
 
Atom Publishing Protocol
Atom Publishing ProtocolAtom Publishing Protocol
Atom Publishing ProtocolRichard Metzler
 
Grundlagen des World Wide Web
Grundlagen des World Wide WebGrundlagen des World Wide Web
Grundlagen des World Wide WebJakob .
 
Autodesk Productstream Inventor Dateien importieren
Autodesk Productstream Inventor Dateien importierenAutodesk Productstream Inventor Dateien importieren
Autodesk Productstream Inventor Dateien importierenwagi2
 
XML-Socket-Server zur Kommunikation mit Flash
XML-Socket-Server zur Kommunikation mit FlashXML-Socket-Server zur Kommunikation mit Flash
XML-Socket-Server zur Kommunikation mit FlashStephan Schmidt
 
ArcGIS Enterprise Content Migration mit FME
ArcGIS Enterprise Content Migration mit FMEArcGIS Enterprise Content Migration mit FME
ArcGIS Enterprise Content Migration mit FMESafe Software
 
Vorstellung Open Social Ipc 2009
Vorstellung Open Social Ipc 2009Vorstellung Open Social Ipc 2009
Vorstellung Open Social Ipc 2009fruske
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisQAware GmbH
 
OpenSocial und Apache Shindig
OpenSocial und Apache ShindigOpenSocial und Apache Shindig
OpenSocial und Apache ShindigMayflower GmbH
 

Ähnlich wie OAuth 2.0 (13)

Datenbasierte Services mit Entity Framework und Co.
Datenbasierte Services mit Entity Framework und Co.	Datenbasierte Services mit Entity Framework und Co.
Datenbasierte Services mit Entity Framework und Co.
 
Datengetriebene Web APIs mit Entity Framework
Datengetriebene Web APIs mit Entity FrameworkDatengetriebene Web APIs mit Entity Framework
Datengetriebene Web APIs mit Entity Framework
 
PageSpeed Extreme für das große Speed Update 2021
PageSpeed Extreme für das große Speed Update 2021PageSpeed Extreme für das große Speed Update 2021
PageSpeed Extreme für das große Speed Update 2021
 
Atom Publishing Protocol
Atom Publishing ProtocolAtom Publishing Protocol
Atom Publishing Protocol
 
Grundlagen des World Wide Web
Grundlagen des World Wide WebGrundlagen des World Wide Web
Grundlagen des World Wide Web
 
Autodesk Productstream Inventor Dateien importieren
Autodesk Productstream Inventor Dateien importierenAutodesk Productstream Inventor Dateien importieren
Autodesk Productstream Inventor Dateien importieren
 
XML-Socket-Server zur Kommunikation mit Flash
XML-Socket-Server zur Kommunikation mit FlashXML-Socket-Server zur Kommunikation mit Flash
XML-Socket-Server zur Kommunikation mit Flash
 
ArcGIS Enterprise Content Migration mit FME
ArcGIS Enterprise Content Migration mit FMEArcGIS Enterprise Content Migration mit FME
ArcGIS Enterprise Content Migration mit FME
 
Wicket Kurzübersicht
Wicket KurzübersichtWicket Kurzübersicht
Wicket Kurzübersicht
 
PHP im High End
PHP im High EndPHP im High End
PHP im High End
 
Vorstellung Open Social Ipc 2009
Vorstellung Open Social Ipc 2009Vorstellung Open Social Ipc 2009
Vorstellung Open Social Ipc 2009
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der Praxis
 
OpenSocial und Apache Shindig
OpenSocial und Apache ShindigOpenSocial und Apache Shindig
OpenSocial und Apache Shindig
 

OAuth 2.0

  • 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
  • 23. 2326. September 2018 @funkattack 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) https://tools.ietf.org/html/rfc7519 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzO DAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb2 90Ijp0cnVlfQ.N_itXQGXQiAVREinpqu- YHuCq4P2Gp5dIP9cp3vsVcA ‫٭‬https://jwt.io/  Base64(header “.“ payload “.“ sign(header, payload))
  • 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
  • 26. 2626. September 2018 @funkattack 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"}
  • 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

Hinweis der Redaktion

  1. Labormodell Ausgangsmodell
  2. Das ist natürlich nicht ganz fair, aber im Kern richtig. Was passiert hier:
  3. Das ist natürlich nicht ganz fair, aber im Kern richtig. Was passiert hier:
  4. Das ist natürlich nicht ganz fair, aber im Kern richtig. Was passiert hier:
  5. Das ist natürlich nicht ganz fair, aber im Kern richtig. Was passiert hier: