Continuously getting “Refresh token is obsolete” while generating a new token

Sorry, I tagged wrong person. @dominic_ks

My ass getting destroyed by this too

I’m having the same problem here.
I use WP as a headless, and I’m getting obsolete refresh token all the time. Have you find a solution with this?

Are you all sending username and password and a refresh token cookie in these cases?

Hi,

I recently started using the extension and am getting the same issue. Here are the steps that I was able to reproduce this and I hope the steps I followed will be useful for you as well, @dominic_ks.

I use two http clients for this test, Postman and ThunderClient for VS Code, but this can be done with any other two clients.
1. Make a request to /wp-json/jwt-auth/v1/token from Postman with my username and password. I get a 200 with the JWT token and a valid cookie.
2. I make the same request again, to make sure that I get the token, but this time I remove the credentials from the body. I get a 200 with a new JWT token.
3. Make a request to /wp-json/jwt-auth/v1/token/refresh to check if the refresh logic works with the refresh token.
4. On the second http client, in my case the ThunderClient for VS Code, make a request on /wp-json/jwt-auth/v1/token with the user credentials. I get a 200 with the jwt token and there fresh token.
5. I make the same request here as well, without the credentials. Again, I get a 200 with a new JWT token
6. I try to refresh the token with the /wp-json/jwt-auth/v1/token/refresh on the ThunderClient screen. This results in a success and everything is refreshed without a problem.
7. I go back to Postman, and try to get a JWT token, on /wp-json/jwt-auth/v1/token, without requesting a new refresh token. I get an error, but this is alright, because it is part of the expected flow.
8. I try to do the same request, on /wp-json/jwt-auth/v1/token, but this time I also attach the credentials to the request, and I do not clear the cookies in Postman, so the obsolete cookie is also part of the request. I get a 401 error, stating that the token is obsolete.

The only way that the last step can return a new refresh token and JWT token is by removing the cookies from the session in Postman and using the username and password credentials as part of the body.

You can have the same issue if you play with the device parameter around, but I thought that this basic flow should be a nice example to share.

• This reply was modified 3 months, 3 weeks ago by rtinchev.

OK, so do you agree that the answer to my question is yes? That this error message is returned if you supply both a refresh token cookie and login credentials in the same request?

In short, the answer is yes.

• This reply was modified 3 months, 3 weeks ago by rtinchev.

@rtinchev Thanks, just wanted to make sure I’m understanding that. I’m not sure what the correct behaviour should be here, we may need to discuss on GitHub. What would your expectation be? Ignore the refresh token if login credentials have been provided?

In my understanding, that would be the simplest flow for people that are using the authentication tokens.

I am currently working with colleagues of mine that implement the authentication flows on iOs and Android, where on iOs the cookies get chanced automatically, so our guess is that once we get to it, on android the behavior would be the same. So now if the cookie is present and is invalid, we will need to explicitly clear the cached data and try again. That is why we think that the flow you described would probably be the most user-friendly one.

I am curious what your personal thoughts are though ??

It would seem reasonable to do that, we can check with the other contributors, since there may be a convention on how to handle this. I’ve created an issue on GitHub to discuss:

• https://github.com/usefulteam/jwt-auth/issues/128