我对ASP.NET Identity的体系结构有疑问。
这是我的餐具。
- 主要解决方案-业务、数据和Web API项目
- 用户界面解决方案-MVC项目使用Web API
我已经在Web API上实现了身份验证和授权。
我不明白的是，我如何从Web API服务中的UI访问所有user.identity内容？我是否创建一个类来在ApplicationUser/IdentityUser登录后对其进行建模？User类中似乎存在重复。对我来说，我知道授权是在Web API中完成的，所以我并不真正需要所有的属性。但是，如果没有授权操作的列表，UI如何显示授权的模块？
UI是否只检查用户是否通过了UI身份验证并依赖web服务来授权操作？我认为这是分离MVC和Web API的挑战。
为什么要将Web API和MVC项目分开？你这么做有什么特别的原因吗？
当您有两个项目，一个公开Web API，另一个公开使用MVC的UI时，您将有两个独立的应用程序在Web服务器上运行，具有不同的上下文。可以将其视为为为第三方网站构建一个MVC UI应用程序，该网站公开基于web的API服务。
这意味着外部应用程序（MVC）需要代表用户向内部应用程序（Web API）进行身份验证，并以某种方式存储授权令牌，以便对API进行后续调用。不确定您是如何实现这一点的，但可以使用会话变量（不是一个好主意）或加密的授权cookie来实现。
外部应用程序对登录用户的了解仅限于用户发送的身份验证（如用户名或电子邮件）和Web API身份验证返回的响应（其中包含令牌和过期日期）。如果您需要在外部（MVC）应用程序中获得更多信息，您必须：
-
自定义Web API身份验证以包含附加信息-请参阅AspNet Identity 2：自定义OAuth端点响应
-
在您的内部（Web API）应用程序中添加另一个服务，该服务返回您可能想要的关于logged-in用户的任何信息，并在MVC应用程序中进行身份验证后立即调用它。
您必须自己管理/保留外部应用程序（MVC）中返回的信息。
您可能还想在外部应用程序（MVC）上设置ASP.NET标识的单独使用，并将内部应用程序用作OAuth提供程序；但我不认为这是你想要的。
无论如何，我认为您需要重新评估您的体系结构，并考虑将Web API和MVC项目分开。如果在同一个地方部署两个应用程序，这种方法不仅会增加大量麻烦（比如管理您询问的授权），而且意味着服务器要做更多（不必要的）工作，性能也会降低。我看不出你会从这种分离中得到任何好处。