

Using JSON Web Tokens to Authenticate JavaScript Front-Ends on Rails - mirceasoaica
http://zacstewart.com/2015/05/14/using-json-web-tokens-to-authenticate-javascript-front-ends-on-rails.html

======
MoOmer
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...](https://auth0.com/blog/2015/03/31/critical-
vulnerabilities-in-json-web-token-libraries/)

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

~~~
tracker1
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.

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

~~~
tracker1
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.

~~~
ebbv
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.

~~~
tracker1
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.

------
emin-gun-sirer
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](http://research.google.com/pubs/pub41892.html)

[2] [http://hackingdistributed.com/2014/05/16/macaroons-are-
bette...](http://hackingdistributed.com/2014/05/16/macaroons-are-better-than-
cookies/)

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

------
cdnsteve
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.

~~~
eloisius
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.

------
jalada
Did you consider Hawk?
[https://github.com/hueniverse/hawk](https://github.com/hueniverse/hawk)

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

------
atonse
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?

~~~
bweitzman
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

~~~
nly
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).

~~~
bweitzman
Performance may be negligible but how is it unsafe?

~~~
nly
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.

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

~~~
eloisius
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.

------
nly
What is the threat model here?

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

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

