【问题标题】:How would one secure multiple resource servers using OAuth 2.0?如何使用 OAuth 2.0 保护多个资源服务器?
【发布时间】:2012-02-24 00:03:32
【问题描述】:

考虑以下分布式系统,它使用 OAuth 2.0 进行授权,使用 OpenID 2.0 进行身份验证。

在哪里

  1. RS1、RS2 和 RS3 是“资源服务器”(又称为三种不同的 REST API)
  2. APP1 和 APP2 是客户端
  3. AS 是用于管理 OAuth 令牌的“授权服务器”
  4. OPENID 是一个 OpenID 2.0 提供程序。

APP2 使用 RS1,而 RS1 又使用 RS2 和 RS3 上的资源。 RS1、RS2、RS3、APP2、AS 和 OPENID 之间存在信任,因为它们是由同一家公司(但不同团队)开发的。当用户第一次访问APP2时,APP2会自动授权代表用户访问RS1、RS2和RS3上的资源。

APP1 使用 RS2 中的资源,而后者又使用 RS3 中的资源。 APP1是第三方网站,不可信,用户需要明确授权APP1才能访问RS2和RS3上的资源。

关于 OAuth 2.0 的大多数示例都展示了单个资源和授权服务器之间的通信以及如何请求、颁发和管理令牌。

如何使用 OAuth 2.0 保护这一环境?例如,APP2、RS1 和 RS2 是否有自己的客户端标识符和客户端密码(因为它们都是另一台服务器的“客户端”)?如果是这样,当 RS1 在另一个请求(来自 APP2)中间第一次尝试访问 RS2 和 RS3 上的资源时,如何为 RS1 颁发访问令牌?

我已经有 AS、OPENID、APP2 和 RS1,它们是使用 ASP.NET MVC 3、WCF 4 和 DotNetOpenAuth 4 开发的。我正在尝试将 RS2、RS3 和 APP1 引入系统,但很难弄清楚如何资源服务器和客户端之间的授权将起作用。一切都在 IIS 7.5 和 HTTPS 下运行。

【问题讨论】:

    标签: oauth-2.0 dotnetopenauth


    【解决方案1】:

    我假设 APP2 是一个网络应用程序,因为任何其他类型的应用程序一旦下载到客户端计算机就不能被“信任”。

    我认为就使用客户端凭据对受信任的应用程序进行身份验证而言,您是正确的。 DotNetOpenAuth 4.0 beta 尚不支持客户端凭据,但有望在下周左右推出。

    在 OAuth 2 中,客户端凭据将内置到您受信任的客户端中。这些凭据将在运行时交换刷新和访问令牌,这些令牌将发送到资源服务器。您使用 DNOA API 将访问令牌应用于每个出站 HTTP 请求,该 API 将通过另一个对授权服务器的请求自动更新任何过期的访问令牌。

    【讨论】:

    • 是的,APP2 是一个用 ASP.NET MVC 3 编写的 Web 应用程序。
    • 假设“bob”访问APP2,它在访问RS1时有一个访问令牌(代表“bob”)。如何识别从 RS1 到 RS2 的请求是代表“鲍勃”而不是其他人的请求。想到的唯一解决方案是 RS1 对每个用户都有唯一的客户端凭据,并在从 RS2 请求资源时查找这些客户端凭据并使用它。这给凭证管理带来了一些挑战。
    • 既然你说 RS* 是可信的,他们不需要每个用户的访问令牌。只需他们的一组客户端凭据就足够了,再加上他们只需要说出他们正在冒充的用户。例如,RS1 告诉 RS2“给我 bob 的数据,这是 RS1 的客户端凭据”RS2 对 RS1 正在发出请求感到满意,因此用 bob 的数据进行响应。
    • 我想这里的挑战是如何设计一个可以被 RS1(可信)和 APP1(不可信)访问的 API。我希望有更好的方法来模拟来自 APP2 通过 RS1 到 RS2 的用户请求。
    • 如果两个资源服务器共享相同的密钥来解密访问令牌,那么 RS1 可能只是将用户的访问令牌转发到 RS2。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-07-26
    • 2021-11-16
    • 2019-05-11
    • 2019-02-16
    • 2012-07-19
    • 2018-01-14
    相关资源
    最近更新 更多