In fact, you surely must do this in all normal processes. Otherwise, you are forcing your users to go through a full login again.
Given the weaknesses of web tokens like JWT (e.g prone to main-in-the-middle capture and replay attacks), keeping token expiries short is a must. This reduces at least, the opportunities for an attacker to obtain a valid token (via a MiTM attack), and then using it in a replay attack.
If you want to increase token expiry times, you need to add further protections to the communications process such as passing encrypted signature type data such as IP addresses to reduce the risk of a replay attack.
With the rationale below I would advise against it.
I have just asked a similar question:
We chose to do it in a different way, simple due to the following problem: The storage of the access token in the implicit flow might be subject to compromittation, and as such should never be valid for more than its actual lifetime.
Usually, an access token is usable not only from within a browser for doing CORS calls, it can be used with any http client mocking the behavior of the browser, i.e. also in scripting. And opening such an endpoint gives you a fully script-usable API with an infinitely valid access token (or: infinitely renewable access token). Depending on your use case, this may be an issue.
If you have a valid access token you have access to do anything your normally would be able to do with this given access token. So if you trust how they got this token, you can trust them when they want another.
The only downside would be if you're using this to enforce logout after a certain amount of time.