> Something I've seen in more than one service are API clients that perform a fresh login for every call, That largely comes from people copy+pasting examples

> Something I've seen in more than one service are API clients that perform a fresh login for every call, That largely comes from people copy+pasting examples from API documentation, sites like stack overflow, and (because they have been trained on a lot of code that does nothing more bright) LLMs, for the first call they make then following that for every call without even thinking to check if there is any longer expiry period listed on the response when they first pick up a token, even if the subsequent calls are made in immediate succession so there is practically no chance that the session has expired. > If the system design involves a table of valid session tokens That would generally be bad design IMO. If a timestamp is part of the token and the rest of the information used in its generation (except "static" secrets like salts & keys of course) is present too, there is no need to hit the database to verify a token (it can be done directly in CPU only which likely imposes a lot less wall-clock overhead than a DB call or even simple filesystem read) so no need to even store it there in the first place. This will increase the size of the token (it contains the shared source data as well as the result not just, say, a 256bit hash result) but some of the tokens I've seen in the wild seem large enough to contain a full bible chapter anyway so it appears token length is not a concern in many cases.