Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

No, using JWT will not make your application more secure. Continue using cookies. Don't buy into the JWT hype. You'll probably want to add a CSRF token.

You're correct in stating that implementing an OAuth provider is unnecessary.

I suggest reading the OWASP security guides. Start with Session Management Cheat Sheet [0], and after that Cross-Site Request Forgery (CSRF) [1].

Don't fear the cookies, all their gotchas are well documented and understood. There's lots of valid use-cases for stuff like JWT and OAuth, but I wouldn't bother with it at all until you're more comfortable with digging into the AuthN/AuthZ minefield. I'd consider understanding session management with cookies a precursor to trying to do anything fancier.

[0] https://www.owasp.org/index.php/Session_Management_Cheat_She...

[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...

View on HN

> "No, using JWT will not make your application more secure. Continue using cookies"

Cookies vs JWT makes no sense. You can put the JWT in a cookie if you want to.. apples and oranges.

Absolutely. Though, when people say cookies vs JWT, what they mean is:

Cookies: a simple session ID, a random number, stored in a cookie.

JWT: a JSON object stored in local storage that specifies authorization of some user that is authenticated by public key cryptography. JWTs can be configured in many ways, but this is what people usually mean because they want their sessions to be "stateless."

Way way more often than not, the "cookie" solution is better because it's far simpler. JWTs come with a tremendous amount of complexity with few benefits.

My big issue with JWTs: securing images. With cookies, a browser attaches the cookie on the image request. With JWT, a browser does not send it with the request. Cookies are far easier in this case.

JWTs are small enough that they can fit in a URL most of the time. So there's always that option.

I believe it is generally considered unwise to attach your authentication token to the URL, as it's highly likely to end up in a bunch of access logs.

If the token is only good for one use or for a short period of time (minutes not hours) it's probably fine. I've used them in URL's for invite links. One time use that expire after a short amount of time. Probably not perfect for high security applications like banks or health care but for most applications it's fine.

> With JWT, a browser does not send it with the request

Sure it does, just put the JWT in the cookie ;)

This was what I was about to post -- JWT-in-cookie is just about perfect from a security/convenience ratio standpoint is it not? Assuming the HTTP cookie is secured properly (like all cookies normally are), it's the perfect way to serve both browser and non-browser traffic (apps may choose to do a little more work to pull the cookie out of the authentication request and use just the auth header if they want).

Any thoughts? I can't think of anything glaringly wrong with the scheme.

Also, I generally think that if someone has the resources to obtain your JWT it probably doesn't matter if it's encrypted (assuming it's stuff like the user's ID or roles, and not something you shouldn't be putting in there anyway), because the attacker has the time until you revoke the token to do whatever they want as the user.

I'd love to hear why I'm wrong

Sorry for the curt reply, I'm about to fall asleep.

In OP's case, I think they're unlikely to see any benefits to using JWT.

Dealing with authN/authZ can grow fairly complicated depending on the business' requirements. On the surface what you're suggesting seems like it would work perfectly fine for many use-cases, so you're not wrong.

JWT is often immaterial to authentication. One must consider how the service is consumed and through which mediums. Depending on the data's importance, you'll need to carefully consider the security model.

Acquiring someone's cookie or token doesn't always mean full access, nor does it mean you get to repeatedly request new tokens. You could require an additional password check before allowing the user to take certain actions. Two examples of this are GitHub and Google.

Absolutely -- In the end to even invalidate a JWT properly you have to either depend on time (so short-lived tokens + refresh token), or store some sort of blacklist (and then you're back to where you started anyway). The world is probably ready for a microservice that does this that everyone can use -- I saw one on HN a while ago but haven't seen it since.

The big benefit I saw from JWTs was the stateless nature, with the drawback of servers using the same key.

Thanks for the reply! Sleep well.

OP is not familiarized with the topic, and was probably confused and overwhelmed. Not surprising, as getting authentication right can be very challenging.

I told them to avoid JWT and instead use old-school stateful session cookies because there's tons of libs that do most of the work for you, and they're unlikely to see any material benefits at this time from using JWT.

Agreed, the essential piece is finding a reference to understand the security issues.

Technology choices don't replace the need to understand that (although some choices may affect the urgency through unsafe defaults).

Reply on news.ycombinator.com