JWTs provide a more secure and scalable alternative to cookie-based authentication. JWTs contain encrypted user information that is verified on the client-side and transmitted with each request, avoiding the need for database lookups on the server-side. In contrast, cookies require server-side sessions and database lookups to validate the user on each request. JWTs also enable cross-domain requests and work across mobile and web platforms, while cookies have limitations in these areas. Developers are advised to use a third-party service to handle JWT generation and verification rather than implementing it themselves.
1 of 27
More Related Content
Authentication: Cookies vs JWTs and why you’re doing it wrong
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?
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
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
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
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
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
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
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)