c# - Microsoft Identtiy & Identity Server 4 处理流程关系

Question

我正在使用 Aspnet Core 构建一系列微服务。移动应用程序、桌面应用程序和 Web 应用程序将通过 Http REST API 使用服务。

对于用户身份验证，我使用的是 Aspnet Core Identity 平台，但我通过 REST API 公开了用户帐户的创建。客户端使用凭据信息进行 REST 调用，我的 API 使用 Microsoft 身份 API 来配置用户。用户将被授权通过使用 IdentityServer4 的身份验证服务器访问各个资源服务器。

从安全的角度来看，我有两个问题无法找到明确的指导。使用 Microsoft Identity 进行用户创建的 Aspnet Core 项目是否应该位于通过 IdentityServer4 处理身份验证的项目的独立 Aspnet Core 项目中？将两者分开是否有我需要考虑的缺点？

Microsoft Identity API 具有模板和 Razor 视图，可用于从服务器端的角度处理身份验证，包括帐户创建或登录时的重定向等。如果我通过 SPA 或客户端本机应用程序执行所有操作，仅提供一个接受用户信息、通过创建帐户UserManager<T>并返回的POST API 有什么问题UserId吗？

我想提供一个专用的登录页面，类似于 FB/Google/Twitter 等，以便在任何想要授权用户使用我的服务的应用程序中进行身份验证。不过，我通常不会将帐户创建视为 OAuth 流程的一部分。您是否通常允许重定向到帐户创建页面，在成功创建帐户后重定向回客户端，或者该过程通常仅用于通过 OAuth 流进行身份验证？

标签： c#asp.net-coreoauth-2.0asp.net-identityidentityserver4

Answer 1

考虑安全管理 UI 时的要点是如何保护该 UI。目前最安全的方法是使用同站点 cookie 的基于 cookie 的身份验证（MVC 默认使用的方式）。考虑一下何时以及是否选择无服务器 SPA 模式。出于管理目的 - 具有严格后端的应用程序比基于令牌的分布式 api-s 访问更安全。

关于应用程序托管，@VidmantasBlazevicius 是绝对正确的，没有唯一的策略：在一个应用程序中托管所有服务更简单，因此更适合中等负载系统。但是随着用户数量和身份验证请求的增加，您可能希望进行扩展，将管理 UI 与身份验证分开是处理此问题的方法之一。