Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens should be avoided

paragonie.com

Post reply on HN
Print view View original

131–140 of 304 posts

Re: JSON Web Tokens should be avoided

#131

Post by throwaway2016a »

scandox wrote: post #47

I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…

> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies?

Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks.

A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essentially re-implementing something you could be doing in a standard way instead.

Re: JSON Web Tokens should be avoided

#133

Post by falcolas »

justinclift wrote: post #109
falcolas wrote: post #95

Earlier quoted context omitted.

Sure, revocation lists are relatively small. But they need to be available to every server (replication), be proof against server/service restarts (durable), and checked with every request (highly performant). So, a good revocation list effectively requires a database. Not a trivial thing to implement yourself, and a weighty requirement for an otherwise stateless service.

Hmmm, using a database (eg PG) for the authoritative information, with memcached in front sounds like it would be practical for most uses.

At which point you should probably ask yourself: "What value is keeping all of my state inside this token providing me?"

Re: JSON Web Tokens should be avoided

#134

Post by throwaway2016a »

floatboth wrote: post #30
Freak_NL wrote: post #17

Earlier quoted context omitted.

Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period…

Yeah, and that's kinda sad because now you have to check a signature AND query a database!

Two solutions:

1. As other posters pointed out. The blacklist is probably pretty small and can live in memory on your apps servers. If you have a distributed raft network or something to keep it in sync across nodes, even better.

2. You can avoid checking it against the DB unless the API call is sensitive (example: modifies data).

Re: JSON Web Tokens should be avoided

#135

Post by throwaway2016a »

StreamBright wrote: post #15
jacopofar2 wrote: post #7

The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…

Exactly. The session invalidation has to happen using a session store or expiry header or something similar. In this regard JWT is not better than cookies.

> expiry header

JWT tokens have the expiration date embedded in the token. There is no way to force it to expire like you you can with cookies.

Although force is a strong word. Even with cookies if you tell the client to delete a cookie it doesn't mean it has to listen.

Re: JSON Web Tokens should be avoided

#136

Post by fcvarela »

draw_down wrote: post #74
fcvarela wrote: post #6

"Send a header that specifies the "none" algorithm be used" Why would an issuer ever let a client decide what algo to use? "Send a header that specifies the "HS256" algorithm when the application normally signs messages with an RSA public key." Again, under what circumstances would a header be used by the client to ask for a specific implementation? What about encrypted client side cookies - would you let the client…

> Why would an issuer ever let a client decide what algo to use? Right, so, why is this in the spec?

The spec doesn't govern what applications can and cannot accept, it governs what contents are valid in tokens. 'None' is valid, that means my parser library will accept it, it doesn't mean my application must accept the token as valid.

Example: The fact that my service has an http stack which must parse a cookie header doesn't mean my app must accept its contents as valid. There's a lot of confusion on this thread about which components should/must do what things.

Re: JSON Web Tokens should be avoided

#137

Post by falcolas »

throwaway2016a wrote: post #131
scandox wrote: post #47

I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…

> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies? Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essen…

> Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks.

Don't you have to do something similar to invalidate tokens anyway?

Re: JSON Web Tokens should be avoided

#138

Post by tlrobinson »

For my current use-case, one of the appealing things about JWT is there are libraries for just about every language, which makes it easy for 3rd party developers to integrate with my service.

Are there any better alternatives to JWT that have implementations in many languages?

If not, elsewhere in this thread tptacek and others have suggested essentially `base64_encode(crypto_auth(json_encode(object)))` would be sufficient... is there any reason not to just slap a name on that "standard" and publish a bunch of libraries?

Re: JSON Web Tokens should be avoided

#139

Post by pilif »

throwaway2016a wrote: post #131
scandox wrote: post #47

I use stateful JWTs for session management, storing them in localStorage. If someone can exfiltrate the token, they will get a week long authorization, as well as some identifiable information (username, name and role). Probably I can achieve the same overall system with cryptographically secure session cookies, that are persisted in a database, or other store that is accessible across multiple servers. I guess it wo…

> So overall while I don't know how right he is, I feel like maybe he has a point. Why not just use cookies? Because in a highly distributed system hitting a database to validate authorization is expensive and causes bottlenecks. A cookie that requires you to hit the database does not solve that issue. Although if the cookie was signed some way that can be cryptographically verified then great. But then you are essen…

cookies have one advantage over localStorage and custom headers though: They can be set by the server in a way that client-side JS code doesn't get to see or change them.

This makes abusing XSS vulnerabilities to get to the token slightly harder.

Post reply on HN