How to implement authorization/authentication with access/refresh tokens using JWT?

Question

JSON Web Token

Please explain the key features of the job.
I understand that an access token is needed to authenticate requests, it lives for 15-30 minutes.
I understand that a refresh token is needed to renew an access token, it lives much longer, for example 30 days.

I don't understand:
1. Let's say we log in, create 2 tokens - access and refresh, the last one is written to a special session table in the database, right? (but it's not entirely clear what we store, only the lifetime comes to mind)
If we write down the signature, we can get it anyway using user data.
Record user agent - what if the user updates the browser?
IP - and if it changes wi-fi or switches to SIM?
2. Where do we write these tokens? Someone says access is written in httpOnly cookie, someone says that we write refresh there.
And we can, for example, write both there? (Example - the user makes a request with an expired access token, we check the refresh, if it passes the check, we issue a new access).
The only thing is that you will have to set the cookie on refresh for the entire application (that is, 2 tokens will go away with each request, but why is still unclear), and not only on /auth , like access (well, or make a separate request /auth/refresh -tokens ).
3. Will both of these tokens be JWTs?

Answer 1

3. Will both of these tokens be JWTs?

JWT is a string formed in accordance with RFC7519 . If the format is correct, it's a JWT; if not, it's not a JWT. If you print a JWT token on paper and use it as a seed bag, these tokens will not stop being JWT tokens. That is, the scope does not affect in any way whether it is a JWT or not - only the format of the token itself.
---
The essence of Access and Refresh tokens is that you can have 10 different servers, one of which is used for authorization. On the authorization server, you generate tokens and communicate them to the client, in some way, the security and convenience of which suits you. Someone sends cookies, someone sends direct server responses. The remaining 9 servers accept requests containing Access tokens. Here, too, you can do it in different ways. You can pass the token in GET parameters, you can use it in cookies, you can use it in the body of the request, you can use the Authorization header - again, this is up to you, depending on which method seems more convenient or safer to you. These 9 servers have the public keys of the authorization server, or they can contact the authorization server for them. Using these public keys, they check the Access token for validity, and if everything is fine, they execute the request in which this token was, pulling out, for example, the identifier of the current user from the token and using it further. These 9 servers themselves do not generate tokens at all. They only test them. Accordingly, they do not need to store specific tokens in the database or in the cache in order to verify the legitimacy of the request, they only need the public key of the authorization server, with the private part of which it signs these tokens. This simplifies the logic on their side, and they can focus on their narrow tasks. Accordingly, they do not need to store specific tokens in the database or in the cache in order to verify the legitimacy of the request, they only need the public key of the authorization server, with the private part of which it signs these tokens. This simplifies the logic on their side, and they can focus on their narrow tasks. Accordingly, they do not need to store specific tokens in the database or in the cache in order to verify the legitimacy of the request, they only need the public key of the authorization server, with the private part of which it signs these tokens. This simplifies the logic on their side, and they can focus on their narrow tasks.
The authorization server deals only with the generation of tokens. It is he who decides that, for example, an Access token should live for 3 minutes, and a Refresh token for 30 days. It makes its own checks of any data that it can get (IP, UA, session ID, and so on) - you decide and write the logic of what checks to do and how. If you think that on the full moon you need to refuse to generate a token for the Firefox browser to users from Kenya, program the system exactly like that, because the JWT library will not automatically do such checks for you - this is not its purpose. Its purpose is to validate and create JWT tokens from the data you give it as input. Among these data may be user identifiers, sessions, etc., if you yourself wanted to put them there.
When you request a new Access token, passing in the Refresh token as parameters (again, you can pass it in many ways depending on your tastes and how you programmed the server), the authorization server checks its validity and decides whether to issue a new token or no. It is quite possible to build a system so that the Refresh token does not have to be stored in the database on the side of the authorization server, because all the necessary data can be placed directly in the payload of the token - it is still signed, so if the client replaces the user ID there, the token will not pass validation .
A chip with Access and Refresh tokens is needed in order to organize the distributed work of several servers. If you generate tokens on the server, and then on the same server accept requests that use the Access token, you are doing something wrong, because in such situations it is not necessary to fence such an architecture, and pass the Refresh token along with the Access- The API server does not need a token either, because generating new tokens is not its concern.
A little higher, I wrote that client-side tokens can be passed in different ways depending on preferences: in cookies, in GET parameters, in the request body, or in the Authorization header. Good practice is when you pass them in the Authorization header and nothing else. Are you making a request to the API server? An Access token is placed in the header. Are you making a request to renew a token to an authorization server? The Refresh token is placed in the header. Everything is simple and the same.