Down below there is a link to an article by tptacek that says that these random session tokens are the simplest and most secure and you should use them if you are able to (which is true in a lot more cases than they are used)
Having had a lot of conversations on this topic in early-stage organizations, it's really common for developers to want to prematurely optimize and move away from random bearer tokens. Something feels "wrong" about them or something. Often we're talking about avoiding one db query per request in an application that is nowhere near any database-imposed bottlenecks.
I much prefer sticking with something simple and easy to comprehend, with fewer potential footguns, and revisiting the decision when we have enough traffic that it could be a concern. Just putting the tokens in Redis can go pretty damn far.
> Often we're talking about avoiding one db query per request in an application that is nowhere near any database-imposed bottlenecks.
The reason you avoid the db query isn't about trying to keep the db from being overloaded, it's that you can handle the request far away from the DB without needing to wait for the latency of hitting the DB.
Which is also still a complete premature and unnecessary optimization for most people. And then someone realizes their use case requires revocation so they add a DB check anyways.
https://fly.io/blog/api-tokens-a-tedious-survey/