You Can Build It. But Should You?
"We just need to add login."
I heard some version of that request countless times during
my time at Auth0. Authentication was another feature on the
roadmap, something to implement before launch.
But what looked like a straightforward requirement often led
to much bigger conversations about security, user experience,
and the decisions teams had already made.
This is where I discovered one of the hardest parts of being a technical advocate: knowing when helping someone means challenging what they're asking for.
When Security Meets User Experience
A common problem, still today, is that authentication is often treated as a feature. But it's an architectural decision. A team designs what feels like the ideal user journey. Then authentication gets added later as a requirement.
Suddenly the dev team is encountering redirects, sessions, permissions, token lifetimes, consent, MFA, account recovery, security boundaries... All these things weren't considered when the user experience was designed.
From the team's perspective, authentication can look like the thing that broke their nice UX. From the identity and security perspective, the original UX may have been designed around assumptions that simply aren't secure.
The developers' requests often come from perfectly reasonable concerns. They call out the need for branding, user experience, reducing friction, or meeting business requirements.
The problem is that their proposed implementation can introduce risks they hadn't considered.
Authentication is part of the user experience. Good technical architecture and good UX need to be designed together. When identity is considered early, there's room to make security feel natural.
There's often both a technical and human side to a problem.
During my time at Auth0, I encountered variations of the same problem.
A developer wanted to build a custom login page so users wouldn't see Microsoft's sign-in screen. Another wanted silent authentication to work with MFA. Someone else wanted a bookmarked login page to work.
None of these were unreasonable things to want.
The first developer wanted a consistent experience. The second wanted to reduce friction for returning users. The third wanted users to be able to get back to a familiar place.
But each request came with technical and security considerations that weren't immediately obvious.
Take the custom login page. If an application collects credentials intended for Microsoft, it introduces risks that the identity provider is supposed to help manage.
The better question wasn't how do we hide Microsoft's login page?
It was what are we trying to improve about the login experience?
That opened the door to a different solution: customizing Microsoft's hosted sign-in experience without taking responsibility for collecting users' credentials.
In that particular Stack Overflow exchange, the developer eventually came back and confirmed they'd implemented the branding suggestion.
Looking back at that answer, I still stand by the recommendation. But I'd approach the explanation a little differently today.
I'd spend less time defending the inconvenience of a redirect and more time explaining what that redirect is protecting. I'd also be more specific about the alternatives available, like using MSAL with a redirect or popup-based authentication flow, rather than collecting credentials directly in the application.
The goal was never to make the developer abandon the experience they wanted. It was to help them achieve it without taking on risks they didn't need to.
It's not always about the login screen.
MFA brought its own version of this problem. Developers understandably wanted returning users to move through authentication without unnecessary interruptions. But MFA exists to provide additional assurance, and whether a user needs another challenge depends on the authentication context and security policy.
Silent authentication and remembered MFA can be legitimate approaches, depending on session state, policy, and risk. The point isn't to eliminate convenience. It's to understand those constraints before choosing an implementation.
What made these conversations difficult was that authentication often entered the discussion after other decisions had already been made.
The design was approved. The user journey was mapped. Developers were working toward a deadline.
Questioning the login experience at that point could mean revisiting decisions nobody wanted to reopen.
But those decisions were exactly what needed another look.
And now we're building agents.
I see a familiar pattern emerging as we build applications with AI agents.
We're excited about what agents can do. Connect to a calendar. Retrieve documents. Update a customer record. Execute a workflow.
But each new capability raises questions about authority. Whose identity is the agent acting under? What permissions does it have? What happens when it tries to do something it shouldn't? Can that access be revoked?
These aren't questions to leave until the agent is working.
I spent years watching teams discover the implications of authentication after designing the experience around it. I don't want us to repeat that mistake with agent access.
Mobile authentication and agent authorization aren't identical problems. But the underlying engineering judgment carries over. Understand the implications of access and security before deciding how something should work.
Knowing when to push back.
There's always going to be pressure to ship. Another feature, another integration, another capability.
And I understand why developers want straightforward answers. They're trying to solve a problem, meet a deadline, and move on to the next thing.
But understanding security and user experience is part of building software. . And I think we'd make better decisions if we spent a little more time questioning our approach before jumping into implementation.
And as a technical advocate, I've learned that helping someone doesn't always mean giving them the answer they came looking for.
Sometimes that means being willing to 'disappoint' them.