JWT, is it possible to do without Refresh Token in this way?

Question

JSON Web Token

I’m making a website, dealing with JWT and Refresh Token, at first I did everything according to Feng Shui, but then I realized that the Refresh token rotation system is constantly buggy, they still need to be tracked, they load the site’s API and database, and so on. And in general, I decided to remove them completely, it took 3 minutes. And voila, I only have JWT. Everything works great, set JWT expiration to 10 years.
Of course, this will only work without problems until someone steals the JWT token or changes their password.
I don't see the point in fighting the first one. Anything can be screwed up.
And here is the second problem.
After all, if a person changes the password, then all past JWT tokens (which contain only the user ID and his role) will still work for 10 years.
But what if you include another password hash in the JWT token?
And to carry out JWT validation, for example, 1 out of 100 times, comparing this hash in the JWT with the hash in the database?
Of course, you can compare every time, but this will be a big load on the database, and in principle we won’t win anything.
I think it's a good idea, what could go wrong here?

Answer 1

but then I realized that the Refresh token rotation system is constantly buggy, they still need to be tracked, they load the site API and database, and so on.

all this is buggy and loads only in your implementation, for example, I don’t have such problems

But what if you include another password hash in the JWT token? And to carry out JWT validation, for example, 1 out of 100 times, comparing this hash in the JWT with the hash in the database?

and now you have begun to invent your crutches, instead of doing it as recommended and time-tested, you don’t need to do it.

Answer 2

The main essence of JWT is to do without any database calls during authentication and authorization. Judging by

they load the site API and database

and

include another password hash in the JWT token

this is not your case, you are still accessing the database (or will be accessing to compare the hash).
In this case, use simple tokens. Just a string of random characters, no load. They do not need to be decrypted by loading the CPU. They can be used forever, in case of compromise, revoke and create a new one manually (of course, you will have to register buttons for this in the user's personal account). A rotten simple token will not burn the email or authorization attributes, and will not allow forging tokens, unlike a JWT without a refresh.