use jwt store, store jwt in cookie instead #367
HoneyryderChuck
started this conversation in
General
Replies: 1 comment 3 replies
-
Storing the jwt in a cookie seems fairly easy: set_jwt_token do |token|
response.set_cookie('rodauth.jwt', value: token, other_cookie_attrs...)
super(token)
end This also stores it in the authorization header (via Using the other configuration methods you mention also seems to make doing this straightforward. The main drawback seems to be complexity. However, in your case, maybe there are reasons for the complexity that justify the approach? |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
👋 ,
While looking for a solution for a centralized login service and researching rodauth, I got interested in the possibility of using the jwt feature for a "distributed verification" scenario, i.e. a login service using rodauth generates a JWT token with a private key, and this JWT is then fetched by the gateway authorizer module and its integrity verified with a known (to the gateway) public key.
To comply with this scenario, I'd have to be able to: 1) add extra data, logged in user profile details, and 2) store the jwt in a cookie instead (in order to make the token survive page refreshes and not be "leaked" to 3rd party JS code).
1 should be possible by overriding
jwt_session_hash
, while 2 may be possible (?) by overridingset_jwt_token
(session_jwt
may also have to be overridden, as we'd be using AWS KMS).Given that recommendations for such a scenario are unavailable, do you see any particular drawbacks of this approach? Consider also that for 1, I'd rather not keep the session id in the jwt session (as this "rodauth/rack session" would not be reachable from the gateway), but would have to find a way to make this data able to still infer the logged in user if keeping the whole account editing / email verification flows in the login service, while for 2, I'd probably have to set the cookie manually (using
rack
API) with "secure" and "httpOnly" flags, as well as match its lifetime to the lifetime of the JWT (not sure if this is an anti-pattern).Beta Was this translation helpful? Give feedback.
All reactions