Refresh Token Documentation
alteredorange opened this issue · comments
Hello! Great work with Subzero, much easier to work with than other REST platforms I've tried!
I'm a little hung up on Refresh Tokens at the moment. It looks like subzero is set up to accept both cookies and Auth headers for identification. So for local dev, since I can't get cookies to work, I'm returning the JWT token as well in the login response, so that way I can add it to future requests as an Authorization: Bearer ${token} header.
That works great, subzero parses the header correctly, even without a cookie present. But as far as I can tell, there's nothing automated for refreshing the token. If you manually call auth/token_refresh it looks like it just checks if the token is still valid, and then if it is, it creates a new token, and sets a new cookie. As far as I can tell there's not longer lived, separate refresh token, correct? Typically a response is called, and if the JWT is expired, the refresh token is used to create a new JWT without user intervention.
So I'm wondering how this is handled with Subzero. Are you checking expiry times on every request, and then refreshing the cookie if time is almost up? And if it's all manual, is there a way to pass back the token as a response in refresh_token instead of just true? I know it sends it back as an Authorization Header, but it looks like that can't be accessed in client side javascript?
Any help is greatly appreciated, thanks!
Typically a response is called, and if the JWT is expired, the refresh token is used to create a new JWT without user intervention.
The user in this case is the api client and the statement above is not true, it's on the api client to detect and refresh an expired jwt token, the server has no way of forcing a new token on the client (since it does not know how that token is stored)
The server however can "force" a cookie refresh so if you store the jwt as a cookie it can be autorefreshed and that is exactly what transparently happens on subzero-starter-kit (in the internal code of the main container which is part of the commercial product ) https://github.com/subzerocloud/subzero-container/blob/main/openresty/lua/hooks.lua#L67
The logic is as you described, on each request the exp of the jwt is checked and if it's needed, the "refresh" function is called internally on the server side and along with the normal response payload a new cookie is sent.
why can't you get cookies to work?
your http client lib (in whatever stack you are using) should have the option to store the cookies and send them on each request (the browser will do that automatically)
I can confirm, cookies are working well.
Try it with this:
curl -X POST --cookie-jar cookies.txt -d '{"email":"alice@email.com","password":"pass"}' http://localhost:8080/rest/rpc/login
You will get the cookie into the file called cookies.txt
the auth functions have a "nicer path"
curl -X POST --cookie-jar cookies.txt -d '{"email":"alice@email.com","password":"pass"}' http://localhost:8080/rest/auth/login
used like this, it might be a good place (if needed) to configure some custom rate-limiting
Ah, makes sense, didn't notice the Lua script, I'll have to familiarize myself with those! Thanks for the help!!
@alteredorange you did not notice them because they are in a different repository. That repository is used to build the subzerocloud/subzero-development container (so that not to overload the starter-kit with complexity).
That repo is also under MIT but notice that it references a lua module require 'subzero.jwt_auto_refresh' which is not in that repo,
that module is baked in the base commercial image (not OS/MIT)