Implementing Auth in .NET WebApi & SPAs: Why is it still so painful?

I wanted to reboot a conversation about something that has frustrated me repeatedly over the years: implementing authentication in .NET WebAPIs and SPAs (Angular, React, Vue, etc.).

TL; DR: In searching other Reddit posts on this topic, I found this post from a few months back: What do you use as an auth provider?

Microsoft Identity was the top answer, and for good reason—it’s a powerful, tried-and-true solution. But despite its strengths, I find it unnecessarily complex for many of my projects and IMHO, I find it difficult to wrap my head around. Also, it seems so half-baked for being such a mature product. There’s so much work and code to write in order to implement the framework into an app from-scratch.

Is anyone else here feeling my pain?

Implementing Auth Sucks.

It’s unavoidable for any semi-serious app and often times it’s the very first thing you need to implement, significantly delaying any progress you can make on the core functionality of your app. Your app needs to know who your users are in order to deliver personalized information and functionality. It seems so App 101, but getting authentication set up has always felt much harder than its academic course-level assignment would suggest.

I describe the problem to lay-people: “You know that login screen you see on your bank's website or that Sign-in with Google or Facebook button you see?” Everyone, even my non-tech mom understands. “Well, as it turns out, that’s a huge PAIN IN THE ASS to build!” Even mom doesn’t believe that it seems as difficult as it is for such a common use-case.

My process for implementing auth usually looks something like this:

1. Research and pick from a giant list of options: Microsoft Identity, OAuth providers, commercial identity systems, or even rolling my own solution.
2. Google for examples or tutorials that match my stack (e.g., “.NET WebAPI identity example” or “Angular WebApi OAuth tutorial”).
3. Spend hours following a tutorial to the end only to that something doesn’t work as described because of any number of reasons or a change to the tech may have happened since the tutorial was written (e.g. Startup.cs moving to Program.cs)
4. Fiddle with it for hours, scouring forums, stack overflow posts, conversing w/ GPT, to often give up and start over with a different tutorial.
5. Eventually, I get something working and hold onto it for dear life—until I need to implement auth again in a new stack or use a new provider.

I can honestly say that implementing auth solutions is one of the worst parts of my job!

For me, Microsoft Identity works, but it has two big downsides:

1. It’s complex: There’s a steep learning curve, even for experienced developers.
2. It lacks a management UI out of the box or any polished front-end implementation: You’re still stuck building out UI for common workflows like registration / password resets and tools to manage users, roles, and tokens yourself.

What about commercial identity providers?

If you’re willing to pay for it, you can get a polished, managed solution that just works. But for smaller projects or businesses, the cost can be prohibitive. Why should simple auth cost so much?

The case for on-premises auth solutions

This is something I think about a lot. Apps that can run on-premises or offer multiple SSO options are more resilient. They’re impervious to internet outages or any one provider going down. This becomes even more important for apps running in:

• Secure labs
• Disconnected environments (off-grid)
• Industries with strict regulatory requirements

An ideal solution would give administrators the flexibility to turn on or off local or cloud providers as needed—without tying you to a single system (shout-out MSAL)!

What’s your experience been like?

I’m curious:

• What’s your biggest pain point when implementing auth in .NET and SPAs?
• How do you handle it today?
• What would an ideal solution look like for you?

Let’s talk. I’m hoping to learn from others, and maybe we can find a better way together.