Hello all,
I am looking forward to clear my concept behind token refreshing.
I am currently giving a token to client when he login and setting an expiry time of 7 days, so this is after 7 days he will be definitely logged out.
Please explain at what point I can refresh the token ? Should I be using 2 tokens?
And where does the concept of session fits in here?
Refresh tokens have the information necessary to get a new access token which would be done when either the access token expires or potentially prior to that point. The refresh token is a separate token from the access token (and separate from any id token).
Session is simply some state you are holding between requests. Since you need to retrieve state on each request (ie load the session) you need some way to identify the right state. Since there may be more than one client that is accessing your service with the same access token, you can’t key the state (session) with the access token and you’d need to have a session token of some kind in order to do that.
access token: grants access to the service
refresh token: grants the right to issue an access token
session token: a reference to some state maintained between requests. Common on HTML interactions, less common with API services
Hello all, please help me with this
Case:- I have a token with some expiry time(say 2 min). According to my model whenever front end makes any requests I am checking the expiry and goodness of token, if not valid then log out.
Problem:- now say I am in my app and it is 1:58 min done after I have got token. According to model after 2 sec the user will be thrown out of app automatically and he need to log in again creating bad UX.
what should I do?
I want to know the refresh token concept working and any other procedures people follows.
Thanks.
I don’t get your problem. 1:58 is less then 2:00 minutes, so the token is valid and the user is logged in. If the next request if over 2:00 mins the token is no longer valid and the user will be logged out.
You might want to rephrase your actual problem you’re trying to solve.
actually, it is if the user continues using the app for 2 or more than 2 min, he should not be thrown out, but when he tries to use the app in new session he should be thrown out.
also, i don’t want to give him a new token everytime.
If we’re talking about browsers and local storage the question would be why not using a cookie in the first place, which does already handle the whole storage for you. Anyways if you’re using any kind of token to keep a session for a user (session cookies also store a token) you’d generally have some kind of max age, which is the maximum amount of inactivity the token does survive. On user requests this max age needs to be reset. In case of a cookie this is done via the cookie expires setting. In case of just a token without serverside storage involved the token must be reissued because the max age and token issueing date are encoded within the token. In case of a token with some serverside storage (e.g. in the db) you could reuse the same token, but change the last time you saw the user in the serverside storage instead of encoding that information in the token itself.
If you encode that info in the token it’s the the time after token generation, because reissuing a new token is the only way to update that time. It however should be the time after the last activity, which is why you need to reissue a new token on each user activity in such a system.