How to come up with your bike for tokens?

Question

PostgreSQL

There is a task to implement the issuance of a token during authentication.
Server side - a bunch of NodeJs and PostgreSQL.
There is a table of users in which there are token and token_life_time attributes.
At the moment, when the client authenticates in the system, he receives a token (the same token is put into the database in the token field of this user), and new Date () + 24 hours is put in token_life_time.
Now this user accesses REST resources with the header Authorization: Bearer <our token is put here>. A token is simply a 90-character string of arbitrary characters. When accessing the resource, the life of the token (token_life_time) is checked. If the current time is less than token_life_time, then the token is still valid and the user has access to resources, otherwise not.
So, it all works out successfully and everyone is happy.
The question is the following.
Now there is a problem with using a randomizer for a token (90 random characters), which is not cryptographically protected in any way. Moreover, I don’t want to generate arbitrary characters, put something important in the token, for example, email and the token expiration date itself. I'm going to implement hashing through bcrypt. Bcrypt can do reconciliation, but I can't get the expiration date from the hash. However, it is needed, since it is necessary to check the relevance of the token.
How to be?

Answer 1

At a minimum: you should check not just a token, but compare the token and the user's session. Otherwise, your bike will be vulnerable to all types of MiTM attacks. Judging by the text, it will be vulnerable every 24 hours - it is enough to wait for the user's authorization and after that you can transfer the token to the attacking script.

Answer 2

It seems to me that from what you described, the option with jwt is best suited ( https://jwt.io/)