There is much to be found in login rates, both successful and unsuccessful.
Something I've seen in more than one service are API clients that perform a fresh login for every call, using the newly issued session token exactly once regardless of how long it might be valid. This pretty much doubles the number of connections and request round trips that need to be handled on either end. No big deal in small amounts but adds up for larger / high rate clients.
If the system design involves a table of valid session tokens, API clients that behave like this can cause that table to grow faster than one might expect, leading to impacts on the session invalidation process or perf issues on the underlying data store.
> 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.
I've abandoned paid services and cancelled subscriptions (or left them 1 star reviews if they're apps) after they repeatedly log me out for no good reason (like an app update that cannot be bothered to preserve and migratie state caches between upgrades) , force me to retype my username each time sporadically etc.
If I am on the same device and requested my credentials to be remembered, then if you sporadically forget it, and there is a reasonable replacement for the service or I can opt to forego it, that service is DONE and has lost me as a customer.
I often say that the login is the front door to your application.
You may want it to look pretty, but what you really want is for folks to get through it as quickly as possible so they can get to the good stuff: the features of your application.
Tracking failure rates over time helps you make sure your front door is working.
(You also want to make sure only the right folks get through.)
I have had failed logins in a old but neccessary microsoft account about 20 times a day from Random IP's in Random Countries over the last 3 years (Could be more, but I only checked so far back)
I can see every attempt, unsuccessful as they are, which is nice, but I'm also surprised that there's no rate limiting
For an account that's never been outside of the American Continent, I'm surprised a Gazillion attempts from Russia, Africa, or even Czechia don't ring any alarms (Or if they do, aren't visible)
There is much to be found in login rates, both successful and unsuccessful.
Something I've seen in more than one service are API clients that perform a fresh login for every call, using the newly issued session token exactly once regardless of how long it might be valid. This pretty much doubles the number of connections and request round trips that need to be handled on either end. No big deal in small amounts but adds up for larger / high rate clients.
If the system design involves a table of valid session tokens, API clients that behave like this can cause that table to grow faster than one might expect, leading to impacts on the session invalidation process or perf issues on the underlying data store.
> 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.
I've abandoned paid services and cancelled subscriptions (or left them 1 star reviews if they're apps) after they repeatedly log me out for no good reason (like an app update that cannot be bothered to preserve and migratie state caches between upgrades) , force me to retype my username each time sporadically etc.
If I am on the same device and requested my credentials to be remembered, then if you sporadically forget it, and there is a reasonable replacement for the service or I can opt to forego it, that service is DONE and has lost me as a customer.
I often say that the login is the front door to your application.
You may want it to look pretty, but what you really want is for folks to get through it as quickly as possible so they can get to the good stuff: the features of your application.
Tracking failure rates over time helps you make sure your front door is working.
(You also want to make sure only the right folks get through.)
I have had failed logins in a old but neccessary microsoft account about 20 times a day from Random IP's in Random Countries over the last 3 years (Could be more, but I only checked so far back)
I can see every attempt, unsuccessful as they are, which is nice, but I'm also surprised that there's no rate limiting
For an account that's never been outside of the American Continent, I'm surprised a Gazillion attempts from Russia, Africa, or even Czechia don't ring any alarms (Or if they do, aren't visible)