Recap: JWT and Cookies for Web Authentication

A brief summary of the talk by Randall Degges titled “JSON Web Tokens Suck”

syIsTyping
don’t code me on that
3 min readMar 9, 2022

--

A while ago I was recommended this talk (2018) about JWT for web authentication (thanks Stav!), I found it a good watch and here’s a brief summary.

Summary

In short, the speaker compares JWT against session cookies in the context of web authentication, and dispels 11 “myths” about JWT.

  • Myth 1: JWT is easier to use. Actual: JWT usage needs third-party libraries and learning curve (how to create and verify it), compared to cookies which are built-in to most server framework.
  • Myth 2: JWT are more flexible. Actual: Cookies can store the same info as JWT, including behaviour like issued-at, expires claims.
  • Myth 3: JWT are more secure. Actual: Cookies can be signed and encrypted also, lesser complexity and no vulnerabilities found (yet).
  • Myth 4: JWT doesn’t require complying with “I accept cookies” regulation. Actual: That regulation technically apply to JWT too.
  • Myth 5: JWT prevents CSRF. Actual: If JWT is stored in cookies (instead of localstorage), it is just as susceptible to CSRF as session cookies. But if JWT is stored in localstorage, it is exposed to greater attack vector, eg: XSS, which is harder to fix than CSRF.
  • Myth 6: JWTs are better for cross-domain authn. Actual: Session cookies can handle cross-domain just as well (speaker goes on to describe one such flow using session cookies).
  • Myth 7: JWT work better on mobile. Actual: No (in the context of web authn) since mobile and desktop web authn functions the same way.
  • Myth 8: JWT are more efficient. Actual: They are not, it is usually larger size.
  • Myth 9: JWT are easy to revoke. Actual: Not true. One way to force revoke a specific token is to change the signing key, but that invalidates all other tokens. Another way is a revocation list, but that means part of the authn flow is centralized.
  • Myth 10: JWT are easier to scale. Actual: Some centralization would be required for the revocation list. Whereas “scaling session management systems horizontally has become a 1-click operation”.
  • Myth 11: JWT are secure by design. Actual: JWT are not created for web authn.

A particular quote that stood out to me:

JWT protocol is not intended for authentication but for single-usage, short duration passing of signed information

This leads to the recommendation for using JWT for these use cases:

  • Handle one-time redirects
  • Resetting passwords

Observations and thoughts

  • Cookies is old tech and may sound unsexy, but still being updated constantly. For eg: the SameSite cookie flag only recently became the default (Chrome: 2020, Android: 2021)
  • Cookies actually have a lot of built-in protections (HttpOnly, Secure and the aforementioned SameSite)
  • OAuth2+OIDC being popular has made JWT popular as well (as the speaker also mentioned). OAuth2+OIDC however goes beyond web and supports many other channels (such as the device grant for IoT)
  • Would it be better to adopt one protocol for each channel (eg: cookies for web), or to adopt the same protocol across channels?

--

--

syIsTyping
don’t code me on that

Security engineer and new dad in Japan. I've learnt a lot from the community, so I hope to contribute back. I write technical articles and how-to guides.