我在使用 OAuth2、WebAPI2 和接口设置项目时遇到了一些麻烦。
场景：
我正在建立一个基本上是 WebApi2 的项目。这个 WebApi 为我的接口提供了业务逻辑和数据。
目前该界面是一个 MVC5 Web 应用程序，但将来我希望能够将其他一些“应用程序”连接到它。这就是 CORS 的用武之地：接口和 WebAPI 可以位于不同的服务器上。
我想使用 OAuth2，因此用户可以通过 Google 和其他提供商进行注册。
问题：
它涉及注册部分：
起初我尝试注册接口 MVC 应用程序并尝试将身份验证令牌传递给 WebAPI。这似乎不是实现这一点的正确方法。
现在我正在考虑在 WebApi 项目中公开一个注册接口，因此如果用户在 MVC Web 应用程序上注册，他们将被重定向到 Api。但这会让人担心，因为对于 MVC Web 应用程序上的每个操作，都需要“此用户是否经过身份验证”调用。
有谁知道这两个选项中的哪一个（或者第三个）更可取？
我知道这很广泛，但请保持温和;-)
这是关于架构部分的一个相当多的问题。
温和一点。第二种方法似乎很复杂，因为您有两个 UI 界面考虑所有应用程序（MVC5 应用程序和现在用于注册的 WebAPI）
因此，通过这样做，您将使您的接口更加依赖于 API 项目，使其紧密耦合。
在第一种方法中，如果只有安全性是您的障碍，那么您可以在服务调用您的 Web API 项目之前和之后加密/解密令牌。
并且使用第一种方法，您可以在本地存储或会话中的您的接口/表示层上保持用户身份验证
WebApi 本身用于应用程序和系统的其他组件（例如业务层）之间的分布式通信。
但是你已经有了接口层，所以我认为没有必要让 WebApi 使用用户界面。
第一种方法会很好。
我们的项目具有相同的架构。
MVC 站点 -> Web API（业务）-> Web API（数据）
业务 API 将开放给第三方开发者，所以我们需要一个 OAuth2 认证。
Web API 只能开放部分功能，不能全部开放，也许你会使用“Scope”，但对我们来说，只有两种 API，第三方 API 和我们网站的 API。
所以我们在身份验证处理程序中做了一些事情，授权标头有一个“承载”方案，为什么不为我们的站点使用一个新方案？
然后它工作。只需为 MVC 站点定义一个新方案，例如。“ASPX”，并存储来自站点的表单cookie，解析它。
由于标头方案不同，我们还可以知道请求来自哪里。
顺便说一句，您应该注意方案的名称。