0

背景

我正在构建一个水疗中心和移动应用程序，它将与一个休息 api 进行通信。我想运行一个单独的身份验证服务器来管理用户（资源所有者），并认为 oAuth2 4.3 资源所有者密码凭据授予对我的应用程序有意义。

如规范中所述，用户（资源所有者）应该直接与我的 rest api（客户端）通信，然后我的 rest api（客户端）应该与身份验证服务器通信。

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

            Figure 5: Resource Owner Password Credentials Flow

但是，我想改变这个流程。我希望用户（资源所有者）直接与身份验证服务器通信，接收令牌，然后使用这些令牌与我的 rest api（客户端）进行通信：

                                                  +----------+
                                                  | Resource |
                                                  |  Owner   |
                                                  |          |
                                                  +----------+
                                                   v
                                Resource Owner     |          
                             Password Credentials (A)
                                                   |
                                                   v  
                                                  +-----------+
      ------------(G)-------- JSON -------------->| SPA / APP |
      |      -----(D)---- Access Token ----------<|           |
      |      |                                    +-----------+
      |      |                                     v         ^
      |      |                  Resource Owner     |         |
      |      |               Password Credentials (B)       (C) Access token
      |      |                                     |         |
      ^      V                                     v         ^
     +---------+                                  +---------------+
     |         |>--(E)--- Token Introspection --->|               |
     |         |                                  | Authorization |
     |  REST   |                                  |     Server    |
     |  API    |<--(F)----- Token Metadata ------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

      Figure 5: Resource Owner Password Credentials Flow (modified)

仅供参考，步骤 (E) 和 (F) 如RFC 7662中所定义。

问题

我想知道你对这个设计有什么想法。我知道这是 RFC 6749 的混蛋，但我认为它更适合我的需求。

  1. 是否有 RFC 6749 中定义的更好的流程可以满足我的需求？
  2. 除了 RFC 6749 之外，还有其他规范可以更好地满足我的需求吗？

我认为我的流程的优点是：

  • 不需要我在水疗中心或移动应用程序中存储密码
  • 允许我的用户直接与身份验证服务器通信以进行登录/注销等。将关注点与我的其余 api(s) 完全分离
  • 允许我更轻松地添加其他 api（微服务），而无需处理用户身份验证。

我认为缺点是：

  • 要求我的身份验证服务器面向公众
  • 需要更多步骤
  • 完全不符合规范
4

1 回答 1

1

OAuth 2.0 由两个协议部分组成：如何从授权服务器“获取”访问令牌，以及如何针对由资源服务器提供的受保护资源“使用”访问令牌。

您从规范中粘贴的图片不包含“使用访问令牌”的部分，因为它在所有授权中都是通用的；它只关注“获取访问令牌”这一环节。

您的图表将两者放在一张图片中，但您混淆了角色：REST API 不是客户端。客户是您的 SPA。API 是资源服务器。然后，您的图片代表（完整的）标准 OAuth 2.0 资源所有者密码凭证流 + 额外的令牌自省部分。

于 2017-03-31T18:56:47.073 回答