Authentication: Cookies vs JWTs and why you’re doing it wrong
•
52 gostaram•35,053 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Authentication: Cookies vs JWTs and why you’re doing it wrong
Semelhante a Authentication: Cookies vs JWTs and why you’re doing it wrong (20)
Último
Último (20)
Authentication: Cookies vs JWTs and why you’re doing it wrong
- 1. Authentication Cookies vs JWTs and why you’re doing it wrong
- 2. The power of an agency at your fingertips
- 4. HowYou’reDoingItNow Cookies are so 20th century
- 5. CookieAuthentication Cookie Auth • Stores a Session ID • Looks up the user in a database • All session information stored server side Concerns • What do you do as your application scales? • How do you route each request back to the same server that stored the session? • As your app grows virally, how do you keep costs down?
- 6. What’saJWT? What’s a JWT? JWT (pronounced jot) is a JSON Web Token
- 7. ThreePartsofaJWT • Header • Declares that it is a JWT • Specifies the decoding algorithm • Claims • Plain text data (encoded with base64) • Typically json object • Signature • Header + Claims encrypted using a server side secret key • Only matches if header and claims aren’t tampered with
- 8. SampleJWT Header Second Part / Payload Third Part / Signature Result
- 9. ServertoClient Successful Login Generate JWT Send to Client
- 10. ClientReceivesToken Check Token Read Claims Base64 Decode
- 11. ServerVerifiesJWT Check Token Decode Token Validate Time
- 12. Implementation • Generated on login and stored in the browser • JWT is submitted with requests as an Authorization header or in a query string Authorization: Bearer {{full JWT}} • Verification happens by regenerating the signature from the original plaintext • After verification, check expiration timestamps • Continue on your merry way
- 13. WhyshouldIcare?
- 15. AuthTransmission • Typically very small (4k hard limit) • Sent with every request to domain – overhead • Authorizing static files included • Cookie specific storage • Can get larger depending on info stored in token (8k soft limit) • Only sent when necessary • Uses signed requests, more cumbersome • Stored in LocalStorage or SessionStorage Cookies JWT
- 17. Cross-domain/CORS • Very difficult across domains • Can be accessed from multiple subdomains • Pre-flight request if using application/json • Works from any domain • Local storage only accessible from storing subdomain • Pre-flight request Cookies JWT
- 18. Security
- 19. Security • Subject to CSRF attacks • HttpOnly makes XSS hard • Secure flag forces SSL -- Man in the Middle (MITM) • Taking cookie with browser access is easy • Not subject to CSRF • No XSS protection • SSL managed in-app • LocalStorage is no different Cookies JWT
- 20. Compatibility
- 21. Compatibility • Less support for mobile • Must be set by server • Can’t use for external API requests • Standard for mobile auth • Can be generated by anyone with secret key • Easy to use for public API Cookies JWT
- 22. Stateless Apparently they’re a band
- 23. Stateless • Contains a session id • Requires a database lookup on every request • Server-side sessions require subsequent requests to hit same server • Scaling difficult • Contains verified user information • No db lookups required • State is stored on client • Scales easily Cookies JWT
- 24. You’recrazy!
- 25. ThingstoRemember • Base64 is NOT secure, encrypt sensitive info • Don’t write your own server-side implementation • There are some good SaaS companies that make this easier on you: • Auth0* • UserApp • Firebase • Keep your secret key SECRET Provided inspiration for this presentation: https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/ *
- 26. FurtherInvestigation • Angular httpAuthInterceptor • Silently add userAgent to JWT • Token heartbeat (refresh on each request) • Two level authentication (GitHub style)