[oopsthrowpass]

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]

> 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]

Cookies 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]

You 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]

Yeah, fair point, maybe could get some wins if serving assets from same domain, but probably should use a CDN for that on different domain