What's the one auth decision you made early that you'd go back and change?
Every product has that one auth decision that made complete sense at the time, but became a pain to change later.
Maybe you set sessions to 30 days because users hated logging in again.
Maybe your permission model started with 3 simple roles and somehow turned into 14 roles nobody fully understands.
Or maybe you stored something that, looking back, you probably shouldn’t have stored at all.
That’s the tricky part about auth decisions. Most bad ones don’t look bad when you make them.
They work. You ship. You move on.
Then more features get built around them, more dependencies are added, and two years later nobody wants to touch that part of the system. And often, it’s not even the big architecture decisions that cause the most trouble. It’s the small defaults nobody thought much about.
A token lifetime. A copied refresh flow. A recovery method that accidentally became the easiest way around everything else.
If you could go back, what’s one auth decision you’d change?
And did you know it was a shortcut when you made it, or did that only become obvious later?
Replies
The part about small defaults is so true. We copied a refresh flow from a tutorial early on and it became a security headache later.
MonoCloud for Startups
@mariusholm haha the tutorial graveyard is real 😄 it works until someone actually audits it.
I think our worst decision was making email as recovery also bypass MFA without realizing it.
MonoCloud for Startups
@lanfranco_iwanaga oops that one stings. the front door is locked, the window is wide open 😅
Mine was deciding not to have accounts at all in the Mac app. That removes most of this list, and then you own licensing instead, so offline validation and a grace window are suddenly your problem.