在 .NET WebApi 和 SPA 中实现 Auth:为什么仍然如此痛苦?

我想重新开始讨论多年来一直困扰我的事情:在 .NET WebAPI 和 SPA(Angular、React、Vue 等)中实现身份验证。

TL; DR:在搜索有关该主题的一些 Reddit 帖子时,我发现了几个月前的这个帖子:您使用什么作为身份验证提供商?

Microsoft Identity 是首选,理由很充分——它是一款功能强大、久经考验的解决方案。但尽管它有诸多优势,但我发现它对我的许多项目来说过于复杂,恕我直言,我很难理解。此外,作为一款如此成熟的产品,它似乎还很不成熟。为了从头开始将框架实现到应用程序中,需要编写大量工作和代码。

这里还有人感受到我的痛苦吗?

**实施身份验证很糟糕。**

对于任何半正式的应用程序来说,这都是不可避免的,而且通常这是您需要实现的第一件事,这会大大延迟您在应用程序核心功能上取得的任何进展。您的应用程序需要知道您的用户是谁,以便提供个性化的信息和功能。这似乎是应用程序入门,但设置身份验证总是感觉比学术课程级别的作业要难得多。

我向外行人描述了这个问题:“你知道银行网站上的登录屏幕,或者你看到的使用 Google 或 Facebook 登录按钮吗?”每个人,甚至我不懂技术的妈妈都明白。“好吧,事实证明,构建它是一件非常痛苦的事情!”甚至妈妈也不相信,对于如此常见的用例来说,它看起来并不那么困难。

我实施身份验证的过程通常是这样的:

  • 研究并从大量选项中进行选择:Microsoft Identity、OAuth 提供商、商业身份系统,甚至推出我自己的解决方案。
  • 在 Google 上查找与我的堆栈相匹配的示例或教程(例如“.NET WebAPI 身份示例”或“Angular WebApi OAuth 教程”)。
  • 花费数小时按照教程进行操作,结果却发现有些东西无法按照描述运行,原因有很多,或者自教程编写以来技术可能已经发生变化(例如 Startup.cs 移至 Program.cs)
  • 花了几个小时摆弄它,搜索论坛、堆栈溢出帖子,与 GPT 交谈,经常放弃并从不同的教程重新开始。
  • 最终,我得到了一些工作并坚持使用它们 — — 直到我需要在新的堆栈中再次实现身份验证或使用新的提供程序。
  • 我可以坦诚地说,实施身份验证解决方案是我工作中最糟糕的部分之一!

    对我来说,Microsoft Identity 很管用,但它有两个大缺点:

  • 它很复杂:即使对于经验丰富的开发人员来说,学习曲线也很陡峭。
  • 它缺乏开箱即用的管理 UI 或任何完善的前端实现:您仍然只能自己构建常见工作流程的 UI,例如注册/密码重置以及自己管理用户、角色和令牌的工具。
  • 那么商业身份提供商又如何呢?

    如果您愿意付费,您可以获得完善的托管解决方案。但对于较小的项目或企业来说,成本可能过高。为什么简单身份验证要花这么多钱?

    本地身份验证解决方案的案例

    这是我经常思考的问题。可以在本地运行或提供多个 SSO 选项的应用程序是。它们不受互联网中断或任何一家提供商宕机的影响。这对于在以下环境中运行的应用程序来说变得更加重要:

  • 安全实验室
  • 断开连接的环境(离网)
  • 监管要求严格的行业
  • 理想的解决方案将使管理员能够根据需要灵活地打开或关闭本地或云提供商 - 而无需将您绑定到单个系统(大声喊出 MSAL)!

    你的体验是什么样的?

    我很好奇:

  • 在 .NET 和 SPA 中实现身份验证时最大的痛点是什么?
  • 今天你如何处理?
  • 对您来说理想的解决方案是什么样的?
  • 我们来谈谈吧。我希望向其他人学习,也许我们可以一起找到更好的方法。