OAuth 2:分离资源服务器和授权服务器

Question

OAuth 2规范让我相信"资源服务器"和"授权服务器"不一定必须是同一个应用程序,但我正在努力弄清楚这在实践中是如何实际实现的.

例如,假设存在以下应用程序:

• 资源服务器
• 授权服务器
• 网络前端
• 第三方客户端应用

场景#1:登录Web前端

• 用户提交登录表单
• web app将凭据POST到auth server(grant_type = password)并接收access_token
• Web应用程序将access_token存储在会话中
• 在每个后续请求中:
  • 从资源服务器获取资源(在授权标头中使用access_token)并在Web前端中呈现它
  • 如果我们获得401然后将用户注销(从会话中删除access_token)

场景#2:授权第三方应用

• 用户从身份验证服务请求授权
• 显示允许/拒绝表单
• 用户被重定向回客户端应用程序,存在授权代码
• 客户端应用程序将代码POST到auth服务(grant_type = authorization_code)并接收access_token
• 客户端从资源服务器传递资源(带有Auth头)

我理解的部分是如何在方案#2中显示允许/拒绝表单之前验证用户.用户可能登录到主Web应用程序,但是auth服务不知道这一点,并且会以某种方式再次需要对用户进行身份验证.auth服务是否也需要支持登录/会话？

我想知道web应用程序是否更有意义负责显示允许/拒绝表单有两个原因:

1. 它将所有UI保存在一个应用程序中
2. 如果用户已登录到Web应用程序,则不会强制用户重新提交其凭据

这是方案#2的一种可能的替代方案:

• 用户从Web应用程序请求授权
• 显示允许/拒绝表单
• web app POST到auth服务器创建新的授权,返回授权代码
• Web应用程序重定向到存在授权代码的客户端应用程序
• 客户端应用程序POST代码以授权服务并接收access_token

处理这个问题的最佳方法是什么？任何一般性意见,建议等都会很棒!

谢谢

Answer 1

您可能要使用的替代方案是：如果您确实要分离流，则可以尝试以下操作：

1. 用户使用Grant_type = code代表服务从auth服务请求授权
2. auth服务实现用户未登录：使用请求参数重定向到Web应用程序，要求Web服务器将用户发回。
3. Web应用程序存储请求参数，然后询问用户名/密码
4. Web应用程序将凭据发布到身份验证服务器（grant_type = password），并接收一个access_token。
5. Web应用程序在会话中存储access_token
6. 该Web应用程序生成一个捕获用户ID的签名令牌，并使用签名令牌作为请求参数重定向回auth服务。
7. 身份验证服务解析签名的令牌，提取用户ID，显示允许/拒绝表单
8. 使用授权码将用户重定向回客户端应用程序
9. 客户端应用将代码发送到身份验证服务（grant_type = authorization_code），并接收一个access_token
10. 客户端从传递的资源服务器中获取资源（带有Auth标头）

Answer 2

OAauth2框架文档：https ://tools.ietf.org/html/rfc6749

（A）客户端通过与授权服务器进行身份验证并提供授权授权来请求访问令牌。

（B）授权服务器对客户端进行身份验证并验证授权授权，如果有效，则颁发访问令牌和刷新令牌。

（C）客户端通过提供访问令牌向资源服务器发出受保护的资源请求。

（D）资源服务器验证访问令牌，如果有效，则服务该请求。

（E）重复步骤（C）和（D），直到访问令牌过期。如果客户端知道访问令牌已过期，则跳至步骤（G）; 否则，它将发出另一个受保护的资源请求。

（F）由于访问令牌无效，因此资源服务器返回无效令牌错误。

（G）客户端通过与授权服务器进行身份验证并提供刷新令牌来请求新的访问令牌。客户端身份验证要求基于客户端类型和授权服务器策略。

（H）授权服务器对客户端进行身份验证并验证刷新令牌，如果有效，则颁发新的访问令牌（以及可选的新的刷新令牌）。