Auth with JSON Web Tokens | Hacker News Reader

Auth with JSON Web Tokens

jpadilla.com

51 pointsjpdlla6 comments

I still don't understand the benefit of JSON Web Tokens over cookies after reading this and the associated blog post by Alberto Pose

http://blog.auth0.com/2014/01/07/angularjs-authentication-wi...

They seem like they are recreating the cookie mechanism using browser local storage and HTTP Authenticate headers, but without any of the associated browser security. I guess the use case would be when you want use a cookie across domains...?

Aren't cookies restricted for a reason? Can't anyone who can execute JS on that domain can swipe the JWT token out of storage and then impersonate the user?

One reasonable use case for JWT is to replace SAML assertions for single-sign on (SSO) from one web application to another, like Zendesk is doing:

https://support.zendesk.com/entries/23675367-Setting-up-sing...

Here, the JWT is stored not in the browser but on the server in the app trying to SSO with the identity provider (in this case Zendesk).

It depends what you mean by the term "associated browser security." The method they are describing stops CSRF attacks dead in their tracks (e.g. if dev set up a GET endpoint that should have been POST/PUT), prevents plaintext cookies from being stored in a nicely organized sqlite db on disk, and limits the scope of xss (xss on a 404 page would get you nothing).

> Aren't cookies restricted for a reason? Can't anyone who can execute JS on that domain can swipe the JWT token out of storage and then impersonate the user?

HTTP-only cookies prevent attacker from swiping yes, but if you have the ability to execute JS on an arbitrary domain, you can just do your XSS attacks there, the browser will attach the cookie, and attacker has already won.

Of course it is not a perfect solution. Just more depth. XSS into a page that inlines auth details = instant pwn, but that was already true anyways. Inlining cred info into my javascript gives be a bad feeling too.

Hey, Matias founder of Auth0 (https://www.auth0.com) here (we wrote the original article).

re: cookies vs xss. Expanding on sil3ntmac comment, based on my experience, it's easier to protect against XSS than protecting against CSRF. For CSRF you have to be aware of: set your cookies to HttpOnly and have a xsrf mechanism in place (which is not straightforward and not the default in many web frameworks, even worse if you start combining technologies). For XSS, you just need to make sure any input is sanitized, which usually most of the web frameworks provide something built-in.

Another interesting side effect of using JWT is that now you have a good cross-platform authentication mechanism that can cross boundaries. You can also achieve that with cookies, but you have to find the same implementation on different frameworks. We talk about this in this blog post about socket.io and json web tokens where it's very common to find PHP and node.js mixed.

http://blog.auth0.com/2014/01/15/auth-with-socket-io/

We will write follow up blog posts about pros/cons, because as usual there is no silver bullet.

Worth mentioning is that JWT is used in the OpenID Connect standard, which is built on top of OAuth 2) for the authentication part. We use it in https://userbin.com to smoothly transfer user sessions between different platforms. Previously we used to roll our own (de-)serialization, signing, session expiration and encryption schemes, but JWT solves a lot of pain and makes it more obvious for developers to understand how this part of our authentication flow works, and are able to use the JWT libraries available in most programming languages.

Aside from the specifications, are there any resources you would recommend for implementing OpenID Connect? The results of a quick Google search are relatively sparse.

Much clearer than the various Internet-Drafts; thanks!

Reply on news.ycombinator.com