3

I see that it's almost standard today to use JWT for modern applications, where the API and the front-end are totally separated, and served from a different server.

I know that browsers will not send cookies to different domains by default, but this can be overcome easily by setting the correct headers in the backend, and configuring the HTTP client accordingly, for example with Axios:

withCredentials: true

And express:

res.setHeader('Access-Control-Allow-Credentials', true);

This allowed me to use express-session, even though the frontend sits on localhost:3000 and the backend on localhost:8000(treated as cross-domain).

The question: Does this pose an increased security risk(cookie being stolen and used, for instatnce) over a JWT token, stored in localStorage? I mean, with cookies you can at least set the httpOnly attribute(what express-session does by default), which will block JS from using it, but with localStorage this is obviously impossible, being that you have to get it via JS.

Any clarification will be greatly appreciated.

i.brod
  • 3,993
  • 11
  • 38
  • 74
  • If you don’t *need* to put the frontend and API on different origins, I would say don’t. Then you’ll be able to use normal cookies and get that (small) HttpOnly benefit. And also consider using session cookies instead of JWT – again, if you can. They’re simple and can be revoked. – Ry- Apr 06 '20 at 11:47
  • Yes, but what about an API that also needs to serve phone apps? Then it has to be cross domain..i can't "serve" the phone app :D. Regarding the revoking: When i use JWT, i still maintain some kind of state, which allows me to revoke tokens/users – i.brod Apr 06 '20 at 12:09
  • If you have to maintain state, which advantages does JWT give you? As for phone apps, they aren’t subject to… any of this, so you can do anything for authentication (session tokens, OAuth, whatever) and store the secret in appropriate secret storage. – Ry- Apr 06 '20 at 12:15
  • Well yes,i thought about it a lot, but it seems to me that any real auth system must maintain some state, because you need to be able to logout/ban users forcefully. there's a huge discussion about this here: https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens . About native apps: So they will completely ignore any CORS issues, and just send the cookie to the relevant domain? – i.brod Apr 06 '20 at 13:36
  • Well, what the default behaviour is depends on the library you use to interact, but you’re not subject to the same-origin policy as a native app so in the end you can add any header to requests going anywhere. Could be a cookie header, could be a standardized or custom `Authorization` header, could be a custom header. As long as your request library doesn’t try to maintain its own cookie jar (and I would consider that undesirable), they’re all more or less the same. – Ry- Apr 06 '20 at 13:39
  • So the bottom line: Why are jwt's being promoted so "hard" these days, in various tutorials and courses?(these courses are mostly beginner level, but still..). Also, what about the topic of CSRF token, which often accompanies the cookie-based auth? Would it even be relevant in a cross domain app?(you can't "render" the new CSRF token in the HTML(in a login form, for instance), because the HTML isn't being rendered by the server..) – i.brod Apr 06 '20 at 13:45

0 Answers0