.NET8 Auth - 现实世界使用的架构应该是什么？

Question

我听说，对于 .NET8，微软为我们提供了完全“固定”的身份验证和授权设置。

现在，当我从模板创建 Blazor 应用程序时，它会构建出一大堆用户管理页面，包括登录等，并且您可以运行数据库迁移来为其创建关联的后端支持。它效果很好，开箱即用，我可以使用 [Authenticate] 标志添加用户、登录和保护页面。

我遇到的第一个问题是我不想使用Entity Framework，也不想使用MS SQL Server。但这又是麻烦了。

我更广泛的问题是 Blazor 项目模板中提供的这种开箱即用的体验并没有尝试解决一种典型的架构，在这种架构中，您有一个用于前端的 Blazor 应用程序、一个用于后端的数据库和一个介于两者之间的 API，用于接收和回复请求。

在我想要使用的这一方案中，身份不应该由 Blazor 应用程序直接处理。相反，实际上应该由 WebAPI 来执行此操作，因为它有权访问数据库后端。

但是，如果我使用模板创建 .NET8 API 项目，Microsoft 会坚持使用以前的 AzureAD 身份验证方法（来自以前的 .NET 版本），并且不会使用随 Blazor 应用程序提供的任何新身份验证内容。

好吧，也许我可以看到他们在 Blazor 应用程序中做什么，并在 API 端实现所有这些。但现在我想知道我是否违背了这里的原则，做了一些微软不打算做的事情。本质上，我担心我在海上迷路并做错了什么。

更复杂的是，即使我在 API 中实现了所有身份，我仍然需要向 Blazor 应用返回某种身份对象，因为它还需要知道用户登录是否正常以及他们具有什么角色。我可以想象一些方法，可以调用 API 端点从 Blazor 应用程序登录并向 Blazor 应用程序返回合适的身份对象。但是，如果有人发送自己的身份对象，那么中间人攻击的可能性又如何呢？它是否因为 Blazor 应用程序和 WebAPI 之间的 https:// 连接而受到保护？

我的问题总结：

1. 我为身份设置 WebAPI，将身份对象返回给 Blazor 是典型的解决方案还是我走错了路？

Answer 1

我总是问自己同样的问题：为什么 Microsoft 模板不为那些想要更适合生产的系统的人提供更多功能？

我现在已经确定的方法是：

1. 使用 Azure Entra 外部 ID（以前称为 Azure AD B2C）进行身份验证，为 UI 创建 Blazor Web Assembly 项目。我倾向于通过 Azure CDN 发布此内容。
2. 为 API 创建 Functions App 并配置 Easy Auth。这里最具挑战性的方面是将 Easy Auth 配置为与 Azure Entra 外部 ID 一起使用（为 Azure Entra 配置它很简单，但对于 Azure Entra 外部 ID 则不然）。

提供如何执行上述操作的完整解释超出了答案的范围...如果您找不到它，我可以尝试将博客文章放在一起。

我希望这至少有助于推动您走向正确的方向。