Refresh Token

[mostafasoufi]

I realized the plugin doesn't support the refresh token which is important for renewing the token in the next requests. so the question is, do you have any plan to add the refresh token in your endpoints?

https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

[contactjavas]

Hi @mostafasoufi , yep i'm aware of this limitation. I'm going to support it. Might be part of version 2.0

[mostafasoufi]

Look at this article, It might be useful while implementation.

https://dev.to/gokayokyay/api-authentication-workflow-with-jwt-and-refresh-tokens-5312

[alexcorvi]

I'm also interested in this feature! great plugin by the way!

[jxunaied]

refresh token is necessary. please implement it

[runebakjacobsen]

Any update on this?

[mostafasoufi]

I implemented the refresh token in a separated plugin and maybe I could be useful for you https://github.com/codelight-eu/wp-api-jwt-auth/blob/master/public/class-jwt-auth-public.php#L93

[runebakjacobsen]

I implemented the refresh token in a separated plugin and maybe I could be useful for you https://github.com/codelight-eu/wp-api-jwt-auth/blob/master/public/class-jwt-auth-public.php#L93

Oh cool, thanks! I'll take a look.

[contactjavas]

Gonna work on refresh token this week. Putting a link here as a reference.

[valstu]

Any updates on this? Is this worked on PR #19?

[sun]

In a quest to find a working implementation for refresh tokens I had to study all the proposed solutions thus far. Here's what I found – hopefully this will help to move this important topic forward:

The effective diff of @mostafasoufi's changes against the source repo (which is a different plugin than this jwt-auth plugin/repo) can be seen here: https://github.com/Tmeister/wp-api-jwt-auth/compare/develop...codelight-eu:master?w=1

• The code introduces an actual refresh token that is separate from the access token. This is a good start.
• But the generated refresh token is not actually a JWT but a random string. It attempts to validate and authenticate it using a custom combination of client and device identifiers, which looks wrong and like a major security issue to me. The code should use the JWT library to generate an actual JWT (refresh) token with the desired longer lifetime, and the already existing JWT decode method to validate it.
• The generated refresh token is stored and set in a cookie. This does not make much sense, because REST API clients normally do not have a cookie storage and the whole point of JWT authentication is to avoid cookie-based authentication. Instead, the refresh token needs to be returned as a response parameter with the initial username/password authentication. Further research showed that sending the refresh token as a (HttpOnly!) cookie is actually best practice to persist the refresh token securely on the client-side for web based clients. However, the value of the cookie should be a JWT.
• The code reduces the lifetime of the access token from 7 days to a shorter timeframe, which is good.

That plugin has 127 forks on GitHub. I did not check yet whether there might be a proper and working implementation in one of the other forks.

The effective diff of #19 can be seen here (unfortunately the branch reformats all code, which could and should have been proposed as a separate PR): https://github.com/usefulteam/jwt-auth/pull/19/files?w=1

• The code does not actually introduce a notion of a refresh token. Instead, the /refresh endpoint relies on (any) other authentication methods to succeed and generates a new access token. But there is no actual concept of a refresh token (next to the access token) that can be used to authenticate on its own and generate an access token.
• The code uses a very odd way to persist the user ID during authentication and make it accessible to the refresh_token() method. It should be able to just simply use the regular WordPress API method for retrieving the current user at this point of the request processing.
• It re-uses the existing generate_token() method to generate a new access token, which is generally good, but as there are almost no other changes, this demonstrates that this PR does not actually introduce refresh tokens - it rather duplicates the /token endpoint onto /refresh.
• It also changes the API version, which is unnecessary as long as existing responses remain the same and only new routes are introduced.

There are 19 forks of this plugin on GitHub. I also did not check those yet.

[sun]

33 now implements a proper refresh token architecture for this plugin. Reviews welcome.

I reimplemented the good ideas from aforementioned attempts, as outlined in my previous comment - and completed the picture with an actual concept of refresh tokens.

The general idea is that the client should not store the username/password credentials themselves. It should only store the refresh token. The common flow looks like this:

Authenticate with actual user login credentials

$ curl -X POST -F username=user -F password=pass https://example.com/wp-json/jwt-auth/v1/token
{
  "success": true,
  "statusCode": 200,
  "code": "jwt_auth_valid_credential",
  "message": "Credential is valid",
  "data": {
    "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvc2VydmljZS50ZXN0LmJubi5kZSIsImlhdCI6MTYyNDQ1NzA2MSwibmJmIjoxNjI0NDU3MDYxLCJleHAiOjE2MjQ0NjA2NjEsImRhdGEiOnsidXNlciI6eyJpZCI6NTA1NjUsImRldmljZSI6IiIsInBhc3MiOm51bGx9fX0.yYmLkcoF6mYoI6naAUv_qvOgfojm2cTG3HW-CvSkkj0",
    ...
    "refreshToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvc2VydmljZS50ZXN0LmJubi5kZSIsImlhdCI6MTYyNDQ1NzA2MSwibmJmIjoxNjI0NDU3MDYxLCJleHAiOjE2MjcwNDkwNjEsImRhdGEiOnsidXNlciI6eyJpZCI6NTA1NjUsImRldmljZSI6IiIsInBhc3MiOiJkZGU1YThlM2ZmYjQ2ZTBiNzY4OWI5M2QwNzk0MTk5OCJ9fX0.UNlvDB2p601BNXDa-OBtt5jnXjttx0bL7VhHDyud8-E"
  }
}

Validate the (refresh or short-lived access) token before it expires

$ curl -X POST -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvc2VydmljZS50ZXN0LmJubi5kZSIsImlhdCI6MTYyNDQ1NzA2MSwibmJmIjoxNjI0NDU3MDYxLCJleHAiOjE2MjcwNDkwNjEsImRhdGEiOnsidXNlciI6eyJpZCI6NTA1NjUsImRldmljZSI6IiIsInBhc3MiOiJkZGU1YThlM2ZmYjQ2ZTBiNzY4OWI5M2QwNzk0MTk5OCJ9fX0.UNlvDB2p601BNXDa-OBtt5jnXjttx0bL7VhHDyud8-E' https://example.com/wp-json/jwt-auth/v1/token/validate
{
  "success": true,
  "statusCode": 200,
  "code": "jwt_auth_valid_token",
  "message": "Token is valid",
  "data": {...}
}

Refresh the access token using the refresh token

$ curl -X POST -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvc2VydmljZS50ZXN0LmJubi5kZSIsImlhdCI6MTYyNDQ1NzA2MSwibmJmIjoxNjI0NDU3MDYxLCJleHAiOjE2MjcwNDkwNjEsImRhdGEiOnsidXNlciI6eyJpZCI6NTA1NjUsImRldmljZSI6IiIsInBhc3MiOiJkZGU1YThlM2ZmYjQ2ZTBiNzY4OWI5M2QwNzk0MTk5OCJ9fX0.UNlvDB2p601BNXDa-OBtt5jnXjttx0bL7VhHDyud8-E' https://example.com/wp-json/jwt-auth/v1/token/refresh
{
  "success": true,
  "statusCode": 200,
  "code": "jwt_auth_valid_credential",
  "message": "Credential is valid",
  "data": {
    "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczpcL1wvc2VydmljZS50ZXN0LmJubi5kZSIsImlhdCI6MTYyNDQ2MzY2OCwibmJmIjoxNjI0NDYzNjY4LCJleHAiOjE2MjQ0NjcyNjgsImRhdGEiOnsidXNlciI6eyJpZCI6NTA1NjUsImRldmljZSI6IiIsInBhc3MiOiJkZGU1YThlM2ZmYjQ2ZTBiNzY4OWI5M2QwNzk0MTk5OCJ9fX0.itnlJVr9eMkMLzFtJR26rkNFfO1A7ZSDSp1ptze9uME",
    ...
  }
}

Note: The /token/refresh response only supplies a new access token. It does not generate a new refresh token.

[sun]

After studying the docs from various authentication service providers, I updated the PR https://github.com/usefulteam/jwt-auth/pull/33 to send and accept the refresh token only in a HttpOnly cookie to meet common security considerations for web based clients.

[holygekko]

I understand it's best practice to store the refresh token in a HttpOnly cookie, however when using wp as a backend for a mobile app it would be undesirable. Cookies can be removed automatically by the mobile os without notice and being HttpOnly the cookie can't be read client side and can't be stored in persistent storage. Is it possible to make this configurable?

[sun]

@holygekko Sure, we can add an option or constant to emit the refresh token in the response body instead.

Most JWT / HTTP client libraries should support to read the response HTTP headers though. The HttpOnly flag only means that the cookie can't be accessed via JavaScript – it's a normal cookie for regular backends otherwise. We're currently integrating this for a mobile app that is using the OkHttp library; I don't have access to the client code, but it seems to be possible without issues.