Authentication: Cookies vs JWTs and why you’re doing it wrong

28,909 views

Published on

Authentication: Cookies vs JWTs and why you’re doing it wrong

  1. 1. Authentication Cookies vs JWTs and why you’re doing it wrong
  2. 2. The power of an agency at your fingertips
  3. 3. WelcometoUtahJS
  4. 4. HowYou’reDoingItNow Cookies are so 20th century
  5. 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. 6. What’saJWT? What’s a JWT? JWT (pronounced jot) is a JSON Web Token
  7. 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. 8. SampleJWT Header Second Part / Payload Third Part / Signature Result
  9. 9. ServertoClient Successful Login Generate JWT Send to Client
  10. 10. ClientReceivesToken Check Token Read Claims Base64 Decode
  11. 11. ServerVerifiesJWT Check Token Decode Token Validate Time
  12. 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. 13. WhyshouldIcare?
  14. 14. AuthTransmission Always tagging along
  15. 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
  16. 16. Cross-domain/CORS
  17. 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. 18. Security
  19. 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. 20. Compatibility
  21. 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. 22. Stateless Apparently they’re a band
  23. 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. 24. You’recrazy!
  25. 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. 26. FurtherInvestigation • Angular httpAuthInterceptor • Silently add userAgent to JWT • Token heartbeat (refresh on each request) • Two level authentication (GitHub style)
  27. 27. DerekPerkins @Derek_Perkins linkedin.com/in/derekperkins github.com/derekperkins derek@derekperkins.com

×