rfc6749 4.3 - 资源所有者与 Auth Server 直接通信？

Question

背景

我正在构建一个水疗和移动应用程序，可以与其他人交流 api。我想要运行一个单独的身份验证服务器来管理用户（资源所有者），并认为 oAuth2 4.3 资源所有者密码凭证授予对我的应用程序有意义。

As described in the specification，用户（资源所有者）应该直接与我的休息 api（客户端）通信，然后我的休息 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

不过，我想改变这个流程。我更希望用户（资源所有者）直接与 auth 服务器通信，接收令牌，然后使用这些令牌与我的其他人通信 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 的混蛋，但我认为它更适合我的需要。

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

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

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

我认为缺点是：

要求我的身份验证服务器public面向
还需要几个步骤
完全不符合规格

Answer 1

OAuth 2.0 由两个协议部分组成：如何 "obtain" 来自授权服务器的访问令牌以及如何 "use" 针对资源服务器提供的受保护资源的访问令牌。

您从规范中粘贴的图片不包含 "using an access token" 的部分，因为它在所有赠款中都是通用的；它只关注 "obtaining an access token".

的腿

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

rfc6749 4.3 - 资源所有者与 Auth Server 直接通信？

rfc6749 4.3 - Resource Owner to Auth Server direct communication?

authentication

rest

oauth-2.0

rfc6749