Rethinking Token-based Security: OAuth 2.0 Security Best Current Practice @jsPoland 2019 Warsaw

Transcript

1. Rethinking Token-based Security: OAuth 2.0 Security Best Current Practice Manfred Steyer SOFTWAREarchitekt.at ManfredSteyer
2. Contents State of the Art Issues leading to new Best Practices Proposed Solution Token Refresh HTTP-only Cookies
3. About me… • Manfred Steyer SOFTWAREarchitekt.at • Angular Trainings and Consultancy • Google Developer Expert (GDE) • Trusted Collaborator in the Angular Team Page ▪ 3 Manfred Steyer Public: Frankfurt, Munich, Vienna In-House: everywhere http://softwarearchitekt.at/workshops
4. State of the Art
5. Flow Folie▪ 5 Client Authorization-Server Resource-Server 1. Redirection 2. Redirection w/ Access-Token 3. Access-Token One central user account Only Auth-Svr. sees the Password Auth. decoupled from Client Tokens provide flexibility No Cookies: No XSRF
6. Most Popular Solution: OAuth 2 and OpenId Connect
7. Implicit Flow w/ OIDC Folie▪ 7 Client Authorization-Server Resource-Server 1. Redirection 2. Redirection w/ Access-Token and Id-Token 3. Access-Token Format: JSON Web Token (JWT)
8. Issues
10. Current Best Practices Document advices against Implicit Flow
11. There are possible attacks! However, this is not new for us!
13. Have we been that naive in the last 6+ years? No!
14. All serious implementations used Implicit Flow together with Best Practices to prevent those attacks!
15. OpenId Connect enforces such Best Practices!
16. Implicit Flow w/ OIDC Folie▪ 16 Client Authorization-Server Resource-Server 1. Redirection 2. Redirection w/ Access-Token and Id-Token
17. Implicit Flow w/ OIDC Folie▪ 17 Client Attacker Resource-Server Hyperlink with Attacker's w/ Access-Token and Id-Token
18. Implicit Flow w/ OIDC Folie▪ 18 Client Authorization-Server Resource-Server 1. Redirection 2. Redirection w/ Access-Token and Id-Token Part of the URL! Browser History? Server Logs?
19. Proposed Solution
20. Code Flow w/ OIDC Folie▪ 20 Client Authorization-Server Resource-Server 1. Redirection 2. Redirection w/ Code
21. Code Flow w/ OIDC Folie▪ 21 Client Authorization-Server Resource-Server 3. AJAX Code 4. Redirection w/ Access-Token and Id-Token 5. Access-Token
22. Code Flow + PKCE w/ OIDC Folie▪ 22 Client Authorization-Server Resource-Server 1. Redirection + Hash(verifier) 2. Redirection w/ Code Hash(verifier) verifier
23. Code Flow + PKCE w/ OIDC Folie▪ 23 Client Authorization-Server Resource-Server 3. AJAX Code + verifier 4. Redirection w/ Access-Token and Id-Token 5. Access-Token Hash(verifier) verifier verifier
24. Code Flow + PKCE w/ OIDC Folie▪ 24 Client Authorization-Server Stealing Tokens using XSS
25. Solutions Prevent XSS by using frameworks Look into CSP (Content Security Policy) Short-living Tokens (~ 10 min)
26. Token Refresh Page ▪ 26
27. Refresh Token Folie▪ 27 Client Authorization-Server Resource-Server Redirection w/ Access-Token und Id-Token and Refresh-Token
28. Refresh Token Folie▪ 28 Client Authorization-Server Resource-Server Refresh-Token Redirection w/ Access-Token und Id-Token and new Refresh-Token
29. Officially, Refresh Tokens are forbidden in the browser as they can be stolen too (XSS).
30. Allowed by the Best Practices Document if … • Know threats and take care of them (XSS!) • Refresh-Token is an one time token! • Log out users if used more than once!
32. Alternative: HTTP-Only Cookies
33. The savest way to store tokens in the browser are HTTP Only Cookies!
34. Client Resource-Server Authorization-Server Resource-Server2 Access-Token Tunnle through backend Prevent XSRF with XSRF-Tokens Needs to be aware of Web Client ("Backend for Frontend") Consequences Same Origin Policy
35. Conclusion Implicit Flow: Don't panic! New solutions: Code Flow + PKCE Refresh Tokens are allowed HTTP-only Cookies: Most secure but inconvinient
36. Contact and Downloads [mail] manfred.steyer@SOFTWAREarchitekt.at [web] SOFTWAREarchitekt.at [twitter] ManfredSteyer d Slides & Examples Public: Frankfurt, Munich, Vienna In-House: everywhere http://softwarearchitekt.at/workshops