djboris88

1. Why do you think localStorage isn’t secure? Of course, it is not secure, nothing is 100% secure, but what are your main concerns?
2. Why would a single-use token be secure? What exact flow would you use to make it secure?

This topic is very debatable. Personally, I like it more when the response itself is with the code that reflects its nature, but I have worked with developers who prefer it otherwise, and I am starting to see the benefits of that.

For example, you send a request for a certain post by ID, and that post does not exist on the server. What code should the response be? 404 or 200? If 404, why is that, if the request was sent to the valid endpoint, and it was correctly processed and returned a valid response? 404 should be only if the request went to an endpoint that does not exist on the server.

This mindset is different than when simply browsing a website. If you open a broken link to a page that does not exist, you would get a 404 page. When loading a page content through multiple Rest API calls, and if you rely on the response codes to know what page to show (the actual or a 404 page), you would then have to differ the calls between themselves. For example, you request the actual page content, and you receive it and are ready to render it, but you also make a request for some other related content to show in the sidebar or below the main content. And that response for some reason comes with a code other than 200 (40x or 50x). If you rely on the response code to automatically redirect to a 404 page, then you will probably get undesired results.

A similar issue is for the 403 status code. If a minor piece of content of the page requires the user to be logged in, but the main content does not, would you redirect the user to the login page only because of that single 403 response?

It all comes down to the way the errors are handled on the client-side. You know that something is off with the server (or endpoint) if you receive a response with a code different than 200, but you still need to check the payload for the actual response status code and handle all of the error cases individually per request. That is what we settled to use. Automatic minimal ‘catch-all’ error handling for the actual response codes, and then individual error handling per request for the response codes in the response payload.

Hi @contactjavas,

Thank you for this. I am just wondering what is your opinion on the need for refresh tokens. I understand that using two tokens, one that is short-lived for authorizing requests, and the other which is long-lived, which serves for requesting new authTokens, in theory provides at least a bit more security.

In practice, it all depends how securely does the client store the tokens. If it is in the local storage, or non-secure and non-httpOnly cookie (which is often not possible due to technical limitations), it really makes no difference. Because if malicious script can access the authToken, it can access the refreshToken as well, right? And if the refreshToken gets leaked, it is even worse than if it is not used at all. authToken would eventually expire, but refreshToken usually lasts for much longer, and can be used for generating unlimited number of authTokens.

I know it is really hard question, but it’s something that has been bothering me for the last few months. What is your opinion on this?

Two things are wrong in your example.

You are completely overwriting the already prepared response in the $response variable.

Second, you are calling the $token variable which you haven’t defined anywhere, so you get the null value for the token key.

Try this instead:

/**
 * Modify the response of valid credential.
 *
 * @param array $response The default valid credential response.
 * @param WP_User $user The authenticated user.
 * .
 * @return array The valid credential response.
 */
add_filter(
    'jwt_auth_valid_credential_response',
    function ( $response, $user ) {
       $response['data']['customResponseData'] = 'Custom data';
       
       return $response;
    },
    10,
    2
);

This way, the already prepared response is still used, as it contains all the valid and required data. We are just adding additional data by creating a new key/value pair in the $response variable. Note that you can name the key whatever you want, but if you name it the same as the existing key, you will overwrite its value.

By default AccessToken expiration is set to 7 days. When you get the expired token error, you should logout the user on the client-side (remove the local data about the logged in user) and redirect them to the login page.

If you want to change the expiration of the AccessToken, you can do it by adding a filter like this:

add_filter( 'jwt_auth_expire', function( $expire, $issued_at ) {
    return $issued_at + ( DAY_IN_SECONDS * 7 ); // Change the number 7 to the number of days you want the token to last
}, 10, 2 );

Yes, that is a workaround, but I can’t import media that way..

I am getting some strange error, now (the database is the same as wordpress now), it says like this:
[ERROR] Article #701: Could not insert post into the database User ’31qz0VbTRaB7242′ has exceeded the ‘max_questions’ resource (current value: 75000)