Refresh access token when calling API

RigorM

Hi @gregtwallace and other users,
Playing around with the API and doing calls (based on what i'm seeing in router.make.go).
You can clearly see that TTL of the token is now() + 4 min.

When doing calls via the API, there is no token keepalive going on (token time reset now() + 4min on each call)
But the web site does not have that problem. AKA, as long as you navigate withing those 4 min, it does not expire.

Is there a way to also have that when doing manual api calls ? (using the curl command)

For now, this is what i'm doing:

Login th get the access token:
curl -isX POST -d '{"username":"admin","password":"<myLocalUserAdminPassword>"}' https://<host URLwith a valid cert>/certwarden/api/v1/app/auth/login

then use the access token to do each secure calls.

I saw the RefreshSessionCookie function but, I'm not sure this applies.. and if it does, I do not know the "key":"value" to pass in POST.

Could someone help on this part ?

Thanks,
JF

RigorM

Ok si I manage to find the key is "Cookie" with the session_token including the variable.

Only thing I need to know are the steps to keep the access_token alive and not expire after 4 min... Like with the web GUI 😁

gregtwallace

You have to use the refresh route. The UI automatically refreshes when the token expires so you don’t notice it happening. If you go into the web ui settings and turn on debug and open the console, you will see the refresh api call.

RigorM

Yes you do see that its call but we don't see the payload it self (key : variable) sent with every command right ?
That would greatly help with dev times 🙂

So, the web UI does the following ?

does a call XYZ
if it gets a 401, do a refresh
does the call again and check if it gets a response of 2xx

?
Thanks

gregtwallace

You've got the gist. If 401, do refresh and try again. If still 401 it bails to the logged out state. The only thing you need to send to the refresh endpoint is the cookie that is issued at login. Its an http only cookie. Refresh issues a new cookie as well as the new access token.

The code is here: https://github.com/gregtwallace/certwarden-frontend/blob/257fcf00b19de17619c0b8c55f92a7d7869a8493/src/hooks/useAxiosWithToken.ts#L87

RigorM

So this way, you always need to keep the cookie somewhere in case you need to do a refresh + always read the acces_token variable to make sure you don't use the old token ?

Is this a JWT limitation ? i've seen alot of APIsonly have a session_token as the a access_token and a refresh just pushes the expiration values further thus keeping the session_token always the same.

Just curious to know how all is built ! 🙂

gregtwallace

Yes, you need to keep the cookie somewhere. It is http only to make it harder to compromise.

The tokens are changed for security. If the access_token is compromised, a refresh extending its use doesn't help. This is why the access_token is changed every refresh. The same is true for the session_token. There isn't really a reason not to change the key. Its easy and adds security. I don't think there is any limitation per se, just best practice.

You can check if the token is expired or not. I didn't code the frontend that way. It just always assumes the token is fine but if it tries an API call that fails for 401, that's what signals its time to call the refresh endpoint and then it tries the original call again afterward.