Hacker News Reader

Comment by lvh | Hacker News Reader

I haven't reviewed said library, so I'm taking your word for it that it's actually limited to that suite :-) The problems with JWT are more complicated than just negotiation, but you should be OK here.

Here's why:

- Some bugs are about negotiation, e.g. key material misuse between RSA and HMAC schemes. They don't affect you, because you don't negotiate.

- Some bugs are about cryptographic implementation, such as not reusing nonces for ECDSA. They don't affect you, because _HMAC-SHA256_ doesn't have most of these problems.

- Some bugs are about specification issues, such as non-mandatory aud (audience) and exp (expiry). Audience shouldn't be a problem for you, because the only audience is you and there's only one secret key, so you get automatic audience restriction via cryptographic binding. Expiry, well, that's on you.

Why did you use JWT to begin with? (What does minting tokens buy you?)

View on HN

Just to clarify, it isn't limited to that suite, but it has a default whitelist of only allowing it. So I COULD change it, but I didn't.

"Why did you use JWT to begin with? (What does minting tokens buy you?)"

Absolutely no compelling reason apart from:

- Never want to roll my own auth, and there were already libraries in elixir and ember to work with JWT, so easy to cobble together

- The HS512 stuff seemed secure enough

- Impression that JWT is generally where things are headed (although I made this decision 2 years ago)

- I can embed some attributes in the token that can be read from the client side

- I liked the idea of authenticating without using a database query.

A lot of these things haven't borne out in the last two years. I still make database queries during auth, and I still retrieve user metadata from an API in my client side. So just to clarify, I'm not attached to it in some way (I never am, to technical decisions). I mainly want to know if I should prioritize moving away from it or not.

Sorry, I didn't mean to come across as bitey. It's just that almost everyone I've talked to who has made this decision and lived with it for over a year has come to the same conclusion: just use a random key and store it in a database :)

Yeah no worries. I sort of agree with you. I don't have any strong opinions on why I chose it apart from that it was easy to implement.

Simpler is almost always better.

Yea, I'm using JWT for authentication, but I still find myself doing a db query for the 'authorization' piece (so I don't bother putting any 'role' information in the JWT, since that seemed rather a bad idea to me, anyway).

Still don't have a great solution for revoking tokens before they expire.

At least it's stateless :)

Revocation isn't such a big deal if you have short lifetimes in your tokens and do auto-refresh (which is quite easy to do in a single page app)

What does it being stateless buy you?

Well, not much from a security standpoint. But I rather don't enjoy dealing with statefulness on the server, so I try to minimize it wherever possible.

Why is the server stateless? I thought you said you end up calling up the db all the time for authz decisions anyway. That sounds like you're still managing a bunch of state server-side.

Unless you're saying "my server process itself is stateful, all the state lives in the database": in which case, yes, but the tokens bought you nothing. If you have random tokens and you store them in the database you have the same situation with no crypto to mess up.

Yes, there's a database (pgsql) for persistence, though no 'session state' is stored there. All of the middleware/services are stateless.

And yes, I realize now that I could accomplish much the same thing without using JWT (a decision made some time ago, when everyone was raving about JWT), but I've got bigger priorities than ripping up my auth system (which to the best of my knowledge is working acceptably well) ATM.

But I do plan to take a look at it and perhaps migrate to something else in the future :)

Sure, sure: I'm not saying you have to go rip anything up right now (unless someone finds a specific vulnerability), but I was trying to eke out what exactly the benefit was :)

Guys, let me compliment you on some nice work here. Maybe there's still a little spit and polish needed, but the important point is it moves the ball forward.

Sometimes there's so much passion here around implementing cool new things that, while those things are important, it can make it easier to forget that simplicity, and better outcomes on average, are not in any way lesser technical advancements. Simplicity also requires good taste to boot imo.

On a side note from one of your posts, doesn't it make you chuckle a little to think "If you've already decided to implement Javascript Object Signing and Encryption (JOSE), whether you want JSON Web Tokens, JSON Web Encryption (JWE), or JSON Web Signatures (JWS), you should question this decision. You're probably making a mistake.", given the massive growth they've seen over 2-3 years in some very high profile cloud systems? But what to do...onward and upward then. :)

Finally I appreciate the dispassionate viewpoints, i.e. "I'm not attached to it in some way (I never am, to technical decisions)". Always to pleasure to work on hard problems and debate with folks who have adopted that perspective.

Anyway, well done.

May I just point out that Microsoft in ASP Net core is really pushing everyone to JWT (for web api / spa anyways).

I am just trying to build apps, I could care less what protocol is in use, as long as it protects the users. Over the last few days of research (including coming across this HN thread https://news.ycombinator.com/item?id=13865459 from a few months ago) I can't help but feel a) trapped into using JWT and b) that is probably the wrong thing to use and I am going to regret it.

Reply on news.ycombinator.com