Should I create different tables to store JWTs (web and mobile API)?

Question

JSON Web Token

I am creating a backend that has both a web part and an API for a mobile application (authorization in different parts goes through different tables). Front on jet. Authorization from the front via JWT.
token table structure: id
token
string(50) user_id
int( ) until time runs out. 3. After the accessToken is rotten, a refreshToken request is sent to the controller to update the tokens.
4. When updating, I look for the user id from the token in the database, if the id of the token from the database matches the id of the token from the request, I update the tokens and send the response (accessToken and refreshToken), if not, then they log and redirect to the autozatsion page.
There is also a daemon on the server that cleans up rotten tokens from the database.
Now there is a need to do the same for the mobile application API. Differences are only in the data transmitted token.
So question. Does it make sense to create a separate table for storing tokens from a mobile application, or do everything in one table? Add a system_id field in addition to user_id? Or search by token (then user_id is not needed at all)?

Answer 1

Why do extra work?

Answer 2

Is this a new feature for jwt - refresh tokens? Can you link where to read?
I do not understand why to store tokens in the database? Why do you need refresh tokens at all. At the dawn of jwt, everything was made much simpler, the client sends a jwt token with each request in any way convenient for him, the server looks that the token will go bad soon, generates a new token and sends it back along with the response, for example, in the same Authorization header, the client sees a new token and replaces the old one. If the token is still rotten - login.