A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share somethin

A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share something that might as well be a password hash. So for example it's not great to use instead of a session key. You could design a system where you have, say, 6 API endpoints and instead of the API endpoints needing access to the authentication db, you use bearer tokens from a single sign on to grant access to the API. That works great until Bob realizes that Eve has got access to his password and hits a password reset to force Eve out the system. But with bearer tokens, Eve still has access until those tokens expire. You could add a check for expiration against the calls, but then we're back to session keys being more straightforward because we're back to having some central information (has Bob's token expired) that needs propagation to the different services. You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again). I think bearer tokens work best for internal proxies / APIs to avoid hitting the data store, they aren't a great replacement for session keys.