[2018 oracle code one] JWT’s suck

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

October 2018
M T W T F S S
« Sep   Nov »
1234567
891011121314
15161718192021
22232425262728
293031  

Past Posts

Java/Java EE

JDBC

Other

[2018 oracle code one] JWT’s suck

October 25th, 2018 by Jeanne Boyarsky

JWTs Suck
Speaker: Randall Degges
@rdegges

For more blog posts, see The Oracle Code One table of contents


JWT (JSON Web Token)

  • pronounced “jot”
  • JSON data
  • cryptographically signed
  • Not encrypted most of the time
  • Prove that some JSON data can be trusted
  • Common use case: Website generates JWT after validating credentials. Website then sends JWT to browser and browser stores in localStorage. Then browser sends to website for subsequent requests.
  • There are stateless and stateful JWT. The later maps to a session id. People don’t use stateful JWTs.
  • 2012 – Spec came out
  • 2014 – began gaining adoption/marketing
  • seven of the first 10 hits on jwt are marketing pitches

Cookies

  • JWT stores session id as JSON blob. In cookie, just a string.
  • Session cookies are underappreciated
  • Use HttpOnly flag
  • Use SameSite-strict flag
  • Use secure flag
  • Browser sends cookie header to website

HTML Local Storage

  • JavaScript only accessible
  • Store key value pairs in browser

Myths about JWTs

  • JWTs are easier to use – JWTs require additional tools, libraries and knowledge to function. Developer effort. Vs session cookies which are built into all web frameworks.
  • JWTs are more flexible – Cookies can store one piece of data per cookie or serialize into a cookie. JWT has claims which are certain pieces of data that always included – ex: when token created/expires. Cookie actually expires at expiration times. Tokens don’t disappear automatically
  • JWTs are more secure – Cryptographically signed and can be encrypted. However, actually using the encryption feature is rare. The spec is complicated and libraries vary in support. Also multiple vulnerabilities in past two years.
  • JWTs prevent CSRF – Cookies are susceptible to CSRF because sent to server automatically. Local storage is safe from CSRF because developer needs to write JavaScript to send the data. However, you are now vulnerable to XSS which is worse. CSRF is far easier to fix than XSS because most websites link to Google Analytics, third party jquery, etc. OWASP recommends not storing any sensitive information in local storage.
  • JWTs are better for cross domain authentication – Good when create temporary token that lasts for 10 seconds. It is used between the login service and your app.
  • JWTs are more efficient than cookies – 179 bytes. If just sign the id part, is 64 bytes. Difference even greater when add data.
  • JWTS are easy to revoke – Could change signing key of application, but that also logs out the other users. Alternatively, use the revocation list pattern so can invalidate one. But now you’ve introduced state/database/cache.

Better use cases for JWT

  • Short duration (one minute or less) for one time use
  • ex: downloading a file, reseting a password

My take: I hadn’t heard of JWTs. So I learned a lot! It was fun hearing the audience questions/comments/statements was fun. That said, I need to read up on the topic to see the other point of view.

Write a comment