Using JSON Web Tokens to Authenticate JavaScript Front-Ends on Rails | Hacker News Reader

Using JSON Web Tokens to Authenticate JavaScript Front-Ends on Rails

zacstewart.com

73 pointsmirceasoaica30 comments

JSON web tokens are indeed pretty dope.

The main vulnerability I worry about when I see it being used is in the implementation by the end user or library, in that you must validate the algorithm used to sign the key [0]; but, many libraries assume that users will read the spec before plopping in a new auth scheme into their app, and don't do this by default.

Secondly, it's important to remember that JWTs can be decoded anywhere, but verified as signed by you.

I've been using JWT-go [1] in my most recent app, and it's been great.

[0]: https://auth0.com/blog/2015/03/31/critical-vulnerabilities-i...

[1]: https://github.com/dgrijalva/jwt-go

JWT actually has two options, you can encrypt the payload, or you can sign it with public/private key. I believe that the path the article uses actually uses the encryption option.

I was going to point this out in my own post, but wanted to finish reading the article first. Of course if you go the signed route, you accept the payload is fully readable, and you must confirm the signature for every request.

Are you implying that the "encrypted route" doesn't need to be verified on every request?

You have to decrypt it to read it... you need the key to do that. If you are referring to revoking tokens before expiration, that's a separate issue, and yes it would require a check... but this would be true of any session based system.

I think the point is regardless of whether you need to decrypt it to read it or not, you should be verifying the content against a signature. Otherwise the content could be forged.

If you use something like jwt-ruby, you get signature verification out of the box.

When it's symetrically encrypted, you have the key, it's verified if it decrypts to a valid value.

When it's asymetrically signed, you are supposed to verify the signature.

Seeing a recently posted vulnerability article, I now see your point... which is funny, in practice, I found JWT so easy to implement a naive solution, I only implemented the pieces I needed as my own authority... One time was JWE (encrypted) with a private key, and the other was asymetricly encrypted, not HS256 ... so there wasn't a means to bypass the intended method used by the system.

Yes, if you are going to implement/support a number of mixed methods for generating tokens (or a use a client library that does), you absolutely need to confirm that the expected header/signature matches.

I made some contributions to one of the open source java implementations(https://bitbucket.org/nimbusds/nimbus-jose-jwt) and I believe the encrypted form of JWTs are referred to as JWEs.

https://tools.ietf.org/html/draft-ietf-jose-json-web-encrypt...

I emphatically recommend that you not use JSON web tokens for a security problem as straightforward as protecting an API. JWT is a horrible kitchen-sink standard; it is cryptographically terrifying.

99 times out of 100, the problems people try to solve around APIs with cryptography are better solved with simple 256-bit random integer tokens.

1) What would your recommendation be if it's not only an API but an ensemble of services that need authentication and authorization? It's feasible to use signed (and maybe encrypted) JWTs for such a purpose, but it'd be interesting to hear your thoughts.

2) To avoid this sort of repeated question, do you have a set of guidelines to avoid common mistakes and generally Do The Right Thing for standard security problems?

This is a little more crypto-oriented, but might be along the lines of what you're looking for.

https://gist.github.com/tqbf/be58d2d39690c3b366ad

This sounds like a use case for Macaroons [1]. A primer and a public implementation can be found here [2]. There's also a JavaScript implementation [3].

[1] http://research.google.com/pubs/pub41892.html

[2] http://hackingdistributed.com/2014/05/16/macaroons-are-bette...

[3] https://github.com/nitram509/macaroons.js/tree/master

I like this approach. Question about the "workflow automation service" you're making. Are you separating each step of the workflow into distinct API's and separate rails apps? If that's the case, how do you manage users across them all? I'm thinking of how this could scale.

Hi! Author here. I wasn't expecting this post to get so much readership when I mentioned my workflow automation service. I don't think it's ready to get Hacker Newsed at this point, but insofar as technical detail is concerned, it's a single Rails app right now. It's a service for integrating different web services without having to write all the OAuth and synchronization code.

When it's demo-able I'll definitely post a Show HN. In the meantime, if you'd like more details I'd love talk one-on-one. Feel free to contact me via my email (at the bottom of OP), or @zacstewart anywhere else.

Did you consider Hawk? https://github.com/hueniverse/hawk

Can't say I did. This is the first I've ever heard of it. Thanks for sharing.

Genuine question: If you are using HTTP over SSL + an auth token as your API transport, do you need JSON web tokens? What do they provide on top of that?

The JSON Web Token is your auth token in this scenario. It also carries some information inside the token; perhaps an email address and name. Just parse the token get the information instead of having to make another API request.

JWTs give you a really lightweight auth token. You don't need to store any state on the server, you don't need to do any encryption/decryption to verify them, you just verify them by hashing. Plus there are all sorts of extensions to the JWT spec for things like timeouts, etc. Plus, the payload is usable by the client, so for example, you're authentication might consist of just sending the user a signed version of the user id or other information that they can use with the API

The lack of server-side auth state only worsens security, and negligible from a performance perspective for common webapps when you're often touching the database anyway (it seems to me you'd really need all your static caches to classify requests and inspect tokens to make this worthwhile).

Performance may be negligible but how is it unsafe?

You can't revoke a token if you have no server-side state to purge. Relying on timeouts is a fairly crude way of going about it.

You can't revoke a singular token but you can change your secret key to revoke every token.

Or, instead of putting the user id in the claims hash, you could have a separate lookup field on the user model explicitly for finding users by JWT. That way, you can have a "log me out everywhere" button on your site. Not quite as smooth as revoking a single authentication, but better than nothing.

jwt's are also useful if "database queries" are expensive (ex distributed systems/webservices etc)

What is the threat model here?

P = NP ?

As one commenter noted, employing XSS to steal the token out of localStorage is a risk.

Thats a risk against using any session based authentication token, right?

Reply on news.ycombinator.com