geekodour
commented
1 week ago i think another option would be to add the jwt token(signed but not encrypted) as a cookie on every whoami.
basically this would mean that we don't need to encrypt it as it'll be httponly and then also i wouldn't need to manually create the cookie to store the jwt which will already come stored along w the other session opaque cookie
also just for clarification, the jwt-session kratos implementation is more around
- we keep using session semantics
- because in some cases we need jwt, we'll send a jwt token in the whois request but otherwise login/logout etc all will keep using session semantics and those flows will not make use of jwt.
did I understand correctly? (apologies for mixing multiple things)
Preflight checklist
Ory Network Project
No response
Describe your problem
We can add jwt to our ory kratos sessions using: https://www.ory.sh/docs/identities/session-to-jwt-cors
https://github.com/ory/kratos/pull/3472
In my usecase, i am planning to send over the jwt to another subdomain using Cookie:Lax and Domain set to the base domain. While this would work, the cookie will be javascript based cookie and if someone gains XSS they'll be able to access the jwt in the cookie I create(the one I plan to send to the subdomain)
Eg. Usecase. I'll be using the JWT to fetch some files via a cloudflare worker and I'll use https://github.com/panva/jose in the cf-worker, this will need the JWT. Instead of sending the JWT in a ajax request, it would be nice to send it in a cookie. This will also be nice eg. load avatar images from the worker of the logged in user etc.
Describe your ideal solution
I think what we have in https://github.com/ory/kratos/pull/3472 super nice, we just encrypt that aswell as an option.
Workarounds or alternatives
I don't see an alternative here, guess we'll be vulnerable to xss exposing logged in user traits and the jwt(even if short ttl) till we have this.
Version
1.2.0 (selfhosted)
Additional Context
No response