0

对于 oauth 条款的不正确使用，我提前道歉。

我有 4 个“派对”，如下所示（在可能的情况下故意不使用 oauth 术语）：

  • 浏览器中的最终用户(javascript)
  • 我们的网站(aspnet)
  • 我们的网络 API (aspnet)
  • 我们的身份验证服务器（aspnet 利用身份服务器 4）

我的使用场景是我们只希望 API 被首先从网站请求页面的浏览器调用。虽然 API 不会发布敏感信息，但我们想引入一层关于被垃圾邮件发送的 API 的复杂性。

我们的最终用户将不会登录。

我想这样的流程类似于：

  1. 浏览器从网站请求某个页面（可能会导致 js 进行 api 调用的页面）
  2. 网站从身份验证服务器请求令牌
  3. 身份验证服务器验证令牌请求来自网站（服务器本身）
  4. 身份验证服务器向网站返回一个令牌
  5. 网站返回页面，包括访问令牌
  6. 浏览器能够使用令牌向 api 发出请求

虽然令人费解，但我相信这至少类似于客户端访问授权流程？

然后，这些令牌可能会被网站或身份验证服务器限制。

是的，我知道这并不能保护 api 免受许多其他向量的影响，但它确实消除了最简单的情况，而这正是我们现在想要实现的。我要补充一点，我没有定义这个要求，我只是想找到一种方法来利用那里的技术来实现它，而不是犯下我自己滚动任何东西的错误。

有人可以确认/否认我可以在这里使用 oauth 流程吗？任何使用给定流程和 IdentityServer 的示例项目？

IdentityServer3 / non-aspnet[core/5] 例子很好，我可以翻译。

4

1 回答 1

0

您描述的是客户端凭据授予，您的网站（客户端）从身份服务器（身份验证服务器）获取访问令牌。然后，该访问令牌可用于调用 Web API（资源服务器）上的端点。

该令牌是一个不记名令牌，任何拥有它的人都可以使用，所以如果您对您的网站通过 HTTP 响应将其传递回浏览器感到满意，那么它就可以正常工作。

我不确定限制令牌是什么意思-一旦铸造，它们将在其一生中有效。我想你可以保持很短的生存时间来实现你想要的单一用途。

于 2016-03-04T21:44:43.897 回答