How do you handle jwt token after it has expired?
I really need to know what is the best thing to handle token in local storage,
On my server, if the token on header is expired, I refresh it, and the token in local storage will not updated after it refresh from server,
I could think each respond after refresh token, I will set the token on each response then set it to local storage, for every request which need the token, but I am sure it is not efficient and too much work, right?
what is the best practice to handle refresh token from server for client-side?
I'm not sure if this helps or not but in many workflows it's the client driving the request. If possible, it may help to simplify the problem:
The client needs a valid token to make a request
If you're able to make this assumption then this can allow you to push the responsibility of token management to the client. Then the server will reject ANY request with an invalid token and return unauthorized to the client. This makes it the clients responsibility to re-auth or refresh by keeping track of token validity.
This separates concerns so that the server doesn't need to have token management and refresh on each request.
I'm basing this on Single Page Application Authentication workflows like described https://auth0.com/docs/architecture-scenarios/spa-api
Related
It is my understanding that, as someone that has recently started using JSON web tokens that, once an access token expires, a new one may be generated using a refresh token.
I currently have some middleware on my server configured such that, if a JWT verification fails, it uses the refresh token to generate a new access token and then attempts the verification process again. If this succeeds, it sends a response with the new access token attached. If it fails, it sends a 401 error.
For this to work, however, the client must send both the access and refresh tokens. My fetch requests are currently configured such that they send the access token under the Authorization header as Bearer [token].
However, when reading the JWT docs, I have come across nothing that refers to the correct manner in which to send the refresh token. A brief search returned that it should be sent in the body of a POST request, however, given I am currently sending both tokens in all fetch requests I make, this would not work for GET requests.
Should I be sending both tokens in all requests? If so how should I send the refresh token in a GET request. Given it is stored in the client cookies, I have considered extracting it from there, though I'm curious if there is a better/more generally accepted method.
I was doing react native app and using OAuth2 and get access token, refresh token and expire in time when I log in my App. I checked my token expire in time when I send a request (GET, POST). If my token expired, then I used a refresh token to get a new access token. My co-worker told me, I don't need check expired time, just use a refresh token to get access token every time I sent the request. I know his way is not properly, but what could be happened if I use his way? Why is it bad to refresh access token every time when I sent requests?
Because it increases the network round trips and makes your application slower than it needs to be, and increases the load on the token service.
That way lies scaling problems and terrible user experience.
Your co-worker probably advised you to do this, which is how I always code these things:
Send the current access token to the API on each request
Eventually the access token will return 401
Then use the refresh token to get a new access token + retry the API call
Eventually the token renewal request will fail with an invalid_grant error and the user has to login again
That is, you refresh only when the access token expires and not on every single request. You avoid relying on the access token expiry time, since APIs can reject tokens for multiple reasons.
I have searched and read many articles where to store JWT whether in session or in cookie but i am unable to know that what is correct place or way to store my JWT in my react redux app
I am storing JWT in session-storage,but it is easily getting exposed from developer tool.And if i try with HTTPonly cookie then that cant be read by javascript.So i am worried where to store JWT token which cant be exposed to user or what should be the step or measures to make the application secured so user doesn't know about jwt token
Please provide suggestion
I think this might help:
Use a httpOnly secure cookie.
Cookies are sent to the server automatically when you make a request to the server, though only the relevant cookies are sent (thankfully).
You should do authentication server side, and not worry about passing a JWT cookie in an individual request from your client side JS. This is the only good way to mitigate a XSS attack that I know of
You should store token in local storage, session storage, and i don't think you can hide any client-side information from users.
I'm working on a javascript application using a REST API.
Authentication is made with JWT tokens stored in cookies
Right now, this scenario is implemented:
user sign in with credentials. Client calls POST /token to authenticate
server responds with a HTTP-only cookie containing the token.
once authenticated, client makes another request to get all user data (GET /me)
I would like to make this process as fast as possible and reduce the number of server requests as much as possible. I thought about combining /token and /me calls and get token and user data in the same request.
That could be done in different ways :
in the claims of the token, but client won't be able to use it as it's in a HTTP-only cookie.
in another, non HTTP-only, cookie but that will be sent uselessly with every future request, so I don't like this solution
in the response body when server sends the cookie after authentication but I have the feeling that it goes against the REST principles as we send user data from an authentication endpoint.
Is there a way to make this process more simple while respecting standard processes and REST principles?
I personnally use Cookies as a storage, but not in HTTPonly mode. In this case, the simplest is to encode the information you need inside the token.
Are you forced to use HTTP-only cookies? Is it an option for you to change it (in fact, for that you must master the authorization server)?
Another thing : using GET to pass credentials isn't safe as you probably pass your credentials in the URL, which can be fetched from server logs. Prefer POST (and HTTPS of course).
Few pointers about JWT and their storage stategies:
Tokens vs Cookies
Where to store the tokens?
Threats of token theft
I am implementing OAuth2 in my PHP web application. Access tokens are distributed to javascript web clients with an expiration of 1 hour, and a refresh token is provided. If the client quits the browser for more than 1 hour the next time they navigate to my web application the access token is no longer valid during the initial request to the resource server. The resource server then returns a unprotected page.
In the event I have:
Expired access token
Valid refresh token
New session
Should the resource server return a unprotected page, and the client using javascript attempt to refresh the access token and if successful force the page to reload? Is that common? Or am I missing something so the resource server isn't called twice?
Currently the client passes the refresh token to the resource server, so technically the resource server could refresh the access token. But, this doesn't seem to be allowed by RFC 6749 which seems to indicate the resource server should never see the refresh token.
"Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the
refresh tokens were issued."
In any case, as you indicate, one never passes a refresh token to the Resource Server. The refresh token is only ever presented to the Authorization Server. But:
In-browser clients such as Javascript clients should use the Implicit grant to get their access token. In that case there is no refresh token that is issued. That should not be a problem with in-browser clients since the user is present in that case, so no refresh token is needed to get a new access token: the user will just authenticate to the Authorization Server again, hopefully leveraging an existing SSO session for that.