3 ms·
In my opinion there are 2 good approaches: If you really need to use JWT-s then store the refresh (just normal UUID looking token that is validated on the back
by oopsthrowpass 3y ago
In my opinion there are 2 good approaches:
If you really need to use JWT-s then store the refresh (just normal UUID looking token that is validated on the backend) token in a httpOnly cookie and JWT in local/session storage, use 10-15 minutes expiration and you are somewhat OK on logout= (the XSS is still maybe exploitable). On logout make sure to invalidate the refresh token.
In my opinion a better way is to just use a good old encrypted/signed/httpOnly/sameSite UUID=123 cookie, convert that to a JWT in your APIGW/BFF when talking to backends.
I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes
- mewpmewp2 3y ago> I would not try to cram JWT-s into cookies they are too big, but maybe these days nobody cares about the extra bytes Why does the length matter compared to when they are sent with cookies or with a special header?
- mort96 3y agoCookies are sent with every request, including to every image or script file or style sheet etc etc. When sent as a separate header, you only set it to API requests.
- mewpmewp2 3y agoYou could use the Path prefix to only send to API endpoints where request has to be authenticated? Or many usually have separate domain/subdomain names for API and static content in the first place. I think having a separate prefix/subdomain would be generally good practice for defining scope which should be authed as well.
- oopsthrowpass 3y agoYeah, fair point, maybe could get some wins if serving assets from same domain, but probably should use a CDN for that on different domain