Gaps between what your auth/session system actually does and what the UI implies is happening?
Posted by dianaska@reddit | sysadmin | View on Reddit | 10 comments
I'm a product researcher looking to understand why authentication and verification flows fail in ways that feel inexplicable to users (not app crashes, but when the user did everything "right" and still can't get in)
Looking specifically at patterns like: verification codes that arrive after they've already expired, session tokens issued before dependent services have caught up, device-switching that silently invalidates everything, retry limits that exist because of carrier constraints the user was never told about.
What I'm missing is the engineering reality: the trade-offs that get accepted, the known gaps between what the backend is doing and what the UI implies.
I have 2 questions in particular:
- What's the gap between what your system actually does and what the UI implies is happening (specifically around auth, session state, or verification flows)?
- What trade-off have you accepted in session handling that would genuinely surprise most users if they knew about it?
gehzumteufel@reddit
It doesn't happen as often these days, but I feel like few websites deal with busted login cookies. And then users get a bad experience.
patmorgan235@reddit
Yeah, like it my session token is garbage, why is the site not clearing it and sending me to the log in page?
Could it be annoying? Maybe, but at least I'm not in a loop until I figure out I need to clear my cookies
gehzumteufel@reddit
I literally just had to tell a user to clear their cookies for that exact loop like 2 weeks ago. Logging into AWS. An invalid session cookie shouldn't result in this bad experience.
digitaltransmutation@reddit
A few that I've run into:
A lot of my users are rural so something that I hear a fair amount of is push notifications simply not arriving. There is a lot of pressure to get rid of SMS but it can be more reliable. TOTP is good since it's offline but in some VPN clients, you have to train the user to attach the code to the end of their password or something dumb like that.
Some services, if you reply STOP or hit the unsubscribe link or report something as spam, will leave you in a 'scrub list' permanently and require manual intervention if you wish to resubscribe. If the website in question uses the same mailer for transactional messages and newsletters, you can become 'unsubscribed' from multifactor.
Depending on jurisdiction, you might be legally required to provide a disclosure to every employee before you can let them enroll biometrics on their company device. Even if it is not required or even suggested this can be a legal risk. Where I work, windows hello is disabled unless you download an enablement package and checkbox that you allow 'the company' to store your biometrics even though it is not leaving your laptop or used for anything but unlocking your laptop.
Some financial institutions detect if you change phone carriers and lock out your account until you can prove that you are still in control of the phone number.
Whenever we onboard a client for remote support we discuss how we can authenticate that whoever we are talking to is really from their company. Sometimes there is a code phrase on the intranet or they can only request callbacks to known business phone numbers rather than dialing in. But for a non trivial amt of clients and different places that I have worked, they will reset anybody's password by name without even trying to verify.
retiredaccount@reddit
Nice comprehensive list. I’d add:
On restore or reinstall of MFA auth app, all connected systems even if “restored from cloud backup” become invalid, requiring MFA reset of all previously stored systems for the client.
On non-SSO based SaaS systems, MFA resets go through the vendor, with no way for an internal admin to their system to reset on behalf of our own clients.
lenswipe@reddit
my pet peeve are websites that send your a 2fa code via email or text(strike one) but with a massive delay so you think it didn't send and try again and then the first one arrives, so you try that one, it fails and then sends you a third one by which time the second one arrives etc.
Responsible_Many7714@reddit
The biggest gap I see is usually between a "valid session" and "real-time risk." Most auth systems are great at checking if a token is technically valid, but they're terrible at reacting to behavioral shifts mid-session. If a user suddenly teleports from New York to Berlin or starts hitting sensitive endpoints they never touch, the session often stays alive until it naturally expires. Real security needs continuous evaluation, not just a one-time check at login. Tbh, if you aren't doing some kind of anomaly detection or short-lived rotating tokens, you're just waiting for a session hijack to happen.
Sad-You2540@reddit
The biggest gap I see is usually between "valid session" and "real-time risk." Most auth systems are great at checking if a token is technically valid, but they're terrible at reacting to behavioral shifts mid-session. If a user suddenly teleports from New York to Berlin or starts hitting sensitive endpoints they never touch, the session stays alive until it naturally expires. Real security needs continuous evaluation, not just a one-time check at login. Tbh, if you aren't doing some kind of anomaly detection or short-lived rotating tokens, you're just waiting for a session hijack to happen.
Beneficial-Gift5330@reddit
So I have this broken down into two results for one flow. All auth goes through MFA.
1) check to see if the credentials are good 2) verify the mfa lines up as expected
If yes to all, then you log in. If no, then you don’t log in
dianaska@reddit (OP)
That great as the intended flow. What I'm not sure is what happens in the gap between those two checks when things go sideways. like when step 1 succeeds but step 2 times out, or the MFA provider is slow, or the user switches apps mid-flow. Does the user get a meaningful signal about which part failed, or just a generic "something went wrong"? And is that a deliberate product decision or just what shipped?