I was thinking to check the user in the database on each request so I
can invalidate the account instantly. Are there any problems with this
flow?
I don't see anything glaringly wrong, but....
There are some downsides. Doing this, requires that every user-interaction lookup your database table. For a small-ish application with not many users, this shouldn't prove a problem. If you've got thousands of users, with thousands of interactions per hour, that's millions of user lookups. Can you database handle this?
The alternative, would be to do this check only when the token is refreshed instead -- that way, you look up the database only once per refresh interval (let's say 15 minutes). Then 1,000 concurrent users will only result in a maximum of 4,000 lookups of the user table per hour (something any db can handle). This also means that only one service in your app (the refresh end point) needs access to the user table, which gives you better control and granularity for protecting your sensitive user data.
Of course, this means that if you need to disable a user, the worst-case scenario you can do this in is 15 minutes. For some applications that might not be acceptable -- so falling back to your check per request might prove a better solution if indeed this is a requirement.
In short, I don't think there's anything wrong with this approach, but I wouldn't recommend it. Do the user check on refresh instead of every request, tokens were built so that every end-point/micro-service could authenticate the user token without having to go back to a singular database table or end-point.
