How to work with JWT refresh token?

Question

PHP

Good day, gentlemen.
Please help, I can't figure out how JWT refresh tokens work.
What I understand at the moment:
1 - the user logs in, in exchange for his login / password he is given a pair of access token & refresh token
2 - on the client they are written in localStorage, and then in each request they are transmitted in the header
3 - until the access token is rotten - everything is fine.
4 - but what to do if it is rotten?

Here the server receives a refresh token and what should he do with it?
Suppose I wrote it to the database before giving it to the client, and now I checked it, it matches, everything is fine - I generate a new pair and give it to the header (something like set-new-jwt:xxxxxx)?

Or is it correct to give the front an answer that the token is rotten, and the front would request a new one?

And more questions:
1) How to deal with several devices with such a scheme? It turns out that the user will be logged out on an inactive device?
2) How to invalidate a token? Just blacklisting tokens (is this the right way?)? I don't see any other option but to change the secret key, but then it will log everyone out...

Thanks in advance for your help.

Answer 1

From this article

Answer 2

2 - on the client they are written to localStorage, and then in each request they are transmitted in the header

No, not in ls, but in the application state.
With the correct JWT approach, this is when the refreshToken is sent in an httpOnly cookie, to which you do not have programmatic access in any way. Plus the access token in the response body.
In the access token, some information is encrypted, usually the lifetime and some starting data.
Here you already write the lifetime and the current date in ls and with each request to the server, intercepting the request, you check whether the lifetime has expired. If it expires, then cancel the request. And instead, you send a request for a refresh (here you already need a refresh token, the lifetime of which is usually much longer than that of access, for example, 30 days versus 1 day) and after a successful refresh, you send the same request that was interrupted
why refresh is only in the httpOnly cookie - If it comes in response with an access token, then two vulnerabilities at once: they can intercept the request and receive both access and refresh tokens at once and quietly enter the system, or steal cookies and access from the application and again get access to everything

1) How to deal with several devices with such a scheme? It turns out that the user will be logged out on an inactive device?

I believe that this is the case - one common refresh for all devices and different access tokens. Thus, it is possible to distinguish between user devices, which ones are logged in, which ones need to be logged out