How can I make sure application got a response with a new pair of access and refresh tokens.
My problem is:
I send a request to to the server to refresh access token and therefore generate a new refresh token. Server generates a new pair of tokens. Sends a response to the application, however application never receives the response, because of a Timeout exception or other connection issues.
Later on user tries to use application again, but refresh token is incorrect, because it was already updated on the server side.
How can I make sure that response was received on application side from the server side?
The easiest solution here would be to not expire the old refresh token, until the associated access token is used first. Alternatively, you can simply not expire the refresh token right away and keep it valid for a while longer.
Related
Please I would like to know how do I keep a user logged in using JWT through a REST API.
Because the token given by JWT expires within a particular time frame and within this time frame it could be possible that the user is still on the app.
I am thinking of allowing the client side application to make asynchronous requests when the token expires.
But the one would also make the client side stall a bit because the token is invalid.
If you have this kind of expiration time, you must renew the token before it expires. You need to add this feature to the client side code. It will be hard with a sync client. Another way is renewing it when the sync client runs on the error message about the expiration and resend the last request, so it can be added to the error handling. If so, then it can be generalized in the error handling code.
I’ve been spending hours and hours on this, this is the first time I am using JWT and would really need some of your thougts.
Right now I store my tokens in separate httpOnly cookies (my access token expires after 15 min and refresh token after 7 days).
I have read that the most secure way to store the tokens is actually using a cookie for the refresh token and in-memory (like in a variable) for the access token.
While I understand this is secure, I do not really understand how it would work in practice. Would it mean that we have to create a new access token with our refresh token on each request? Or is there a way we can make it valid and copied to new variables until it is expired?
I am using react and node btw.
I spent days reading about this too.
From what I gathered a solution would be something like this:
User logs in with login and password.
Server generates a refresh token long lived to be stored as an HttpOnly Cookie, preventing XSS attacks as it can not be accessed by Javascript.
Ideally some sort of blacklist can be used server-side to prevent re-use of refresh tokens that have not reached their expiry but have been replaced.
Generate an access token which can either be stored in localStorage or in-memory (in a variable). The access token has a short expiry life of a few minutes.
If stored in localStorage, the token will not disappear on a reload of the page/browser (F5). It will also be visible in the console/storage.
When using localStorage to check if user is authenticated, the code will try to read the token from localStorage, jwt_decode it and set a user variable with the data that is in the token.
As tokens are not encrypted, just base64, their values can be changed in the dev console. A page that is "role: admin" only will be rendered if the permission is changed. The API will be responsible to check for permissions and reject the request if the token has been tampered.
Afaik, if it is stored in a variable it is a little less visible, it also gets wiped when reloading the page/browser.
When using a variable, to avoid refreshing the access token on every request, we can use the Context API, by creating a Component with the authenticated user context that will wrap the App/Router and then on every page that needs to be protected import and use this context and redirect if needed.
When the access token is not valid anymore, because it has reached its expiry, or because it has been wiped, the API call will get rejected. Intercept this call then call the API refresh route to use the refresh token to generate a new access token.
I use axios with axios interceptor to intercept the failed request, call the refresh route, set the renewed access token, then retry the failed request. (needs to be a GET request to avoid CSRF errors apparently).
In addition (not in place of), a setTimeout can be used to automatically refresh the access token every X minutes to prevent letting it expire.
To log out, remove the cookie (eventually blacklist) and wipe the context / localStorage.
Using axios, axios.defaults.withCredentials = true; makes sure that the cookie is sent with the requests and { headers: { 'Authorization': `Bearer ${access_token}` } } makes sure the access "bearer" token is sent with the request. These can either be set as defaults for every request or per request hence these 2 syntaxes.
Github example with Flask and React
i'm currently developing a multiplayer turn base card game with Unity. The multiplayer architecture will be using websocket (NodeJS Socket.IO) and for the security wise, i'm using JWT with refresh token after access token expired.
Everytime when i emit a request to websocket, i will emit the request along with the access token. By right when the access token has expired, i should revoke a new access token with refresh token. My concern here is the refresh token handling. Should i emit request back to client for getting the refresh token and re-emit the refresh token back to websocket to renew the access token? To renew the access token, I will validate the refresh token through Database to make sure the token is valid. I am wondering the entire process is appropriate and causing any delay(lagging) since it is real-time multiplayer game.
Anyone here able to give some advice?
If you see a traditional HTTP API which is authenticated based on an access/refresh token, the application tracks the expiry time of the token on its own (this means JWT should have an exp timestamp). If the application detects the access token is about to be expired, it fetches as a new one from the server exchanging the refresh token.
Same flow holds valid here
Check the expiry timestamp with current timestamp (minus some buffer time).
If the access token is about to expire, get a new one from the server and proceed with the previous call.
So this is a random question that I can't seem to see an answer to.
I'm using Token based auth in my application. When the login credentials are first sent to the system, a token is returned. That token is then required with each and every request afterwards. When the token expires, a refresh token is used to determine if a new one should be issued. All pretty basic stuff.
What I've noticed is that the token isn't returned to the client with each web call. As in, client sends a message to the server with the token, server sends a response, but doesn't include the token unless it has been refreshed. Now, obviously thanks to client-side storage the token is still available.
My question is whether or not it is a best practice to return the token with each and every response, even if it is unchanged. Or if this really isn't a big deal and I can just stop worrying about it.
Thanks in advance.
Generally no, the response should not contain the token as it's unnecessary at that point - the user has already been authenticated for that specific request and appropriate actions have been taken (either a 200 with data or 401 or whatever).
It is the responsibility of the client to know the token when making a request.
I'm running a mock expressjs server in the back, and ember (ember-simple-auth) on the front with the ember-simple-auth-token addon. I'm using JWT tokens. I'm trying to decide whats the best way to send my user information. Usually when the user submits their credentials I create a new token, store a copy of it in the database (I'm using mongodb), send it to the frontend and then use the token to fetch information user information. I have a /auth/token (which authenticates and sends the token, makes a copy and stores it in the database) & /current_user route which gets called on the initial login, which uses the token and fetches the user info.
Is it better to simply send the user info in the initial payload of the token over having a separate route? Should I be storing a copy in the database in order to do a comparison and retrieve user information?
Also what are the advantages of a token refresh?
you are using Jwt-Auth for authentication.
-According to my knowledge after sending the user credentials u will respond with the token if credentials are correct otherwise send error.
-why are you saving the token in db ?.
you will send token to client (stateless). If client requests for data then we need to check for token. if it validates then return proper response otherwise return token error.
-why you need token refresh?
for security purpose. After response every time change the token.
TTL your token will be valid for some time (say 60 mins). after that it will be invalid.
This is how JWT works.