Switch token storage to cookies?

[eaceaser]

Open for discussion.

Since httpOnly cookies aren't accessible by javascript, it makes sense to store things like auth tokens there vs. in localstorage, as they aren't quite as susceptible to XSS.

I guess the question is, do we ever need access to the JWT in javascript, or are we treating it as an opaque session token? If its the latter, we should just set it as an httpOnly cookie. If its the former, we should probably still store it as a cookie, just not set it httpOnly. That way we don't have to manually attach it to each request.

@ianwessen did we use localstorage here for a specific purpose?

[ianwessen]

No good reason, just making it work as fast as possible at the time. I completely agree with move to cookies.

[eaceaser]

I guess the other question: what do we get out of using JWTs if they're opaque session tokens? If we're not brokering the JWT to another service (or plan to), or are utilizing the assertions in the JWT, they are just longer, harder to invalidate session tokens in practice.

[StoneCypher]

httponly affords no security, as any attacker worth half of someone else's salt is using a custom client based on curl which doesn't honor rules like that

jwts are access tokens, not security tokens, and both cannot and must not be used for a purpose like this. it's like confusing encryption and hashing

[eaceaser]

agreed on the JWT front, but the point of httponly is that it does offer security against in-browser XSS attacks, at least enough that it's preferable to set it if you don't need to access to the cookie from JS. It doesn't really have any bearing on the leakage of the cookie, for which an attacker could use any client they want to access the API.