与OAuth 2.0兼容的跨站点身份验证

Question

就我而言，公司B（域B）拥有一个门户网站，该门户网站链接到我的网络应用程序（域名A）。如果用户单击我的域的门户上的超链接，他/她应该自动登录到我的应用程序。

我无法改变的现有政策：

1. 用户还可以直接登录我的域，无需通过提供用户ID /密码进入门户。
2. 此外，用户配置的现有公司政策是，即使用户通过公司B的门户登录，他们首先需要拥有我公司的用户帐户。因此，用户将拥有门户公司和我公司的帐户。

鉴于这些限制，我的计划是从门户网站提供自动登录。

当用户登录门户网站时，门户网站公司将生成临时令牌（UUID）并将其作为查询参数附加到我的Web应用程序的超链接。当用户点击我的网络应用程序的超链接时，我的网络应用程序将在服务器端收到受保护资源的GET / POST请求。在服务器端，我的Web应用程序将通过https（可能是双向SSL）调用门户网站上的URL，传递临时令牌。门户端以用户ID响应。我的Web应用程序将使用用户的凭据映射用户ID，并为用户创建会话并允许访问受保护资源。

当用户退出门户网站应用程序时，门户网站服务器将在预先指定的URL处向我的Web应用程序发出Https请求，以将用户注销。由于它是双向SSL，因此注销URL受到保护。

我的问题如下：

1. 是否有基于标准的方法来实现上述方案。在不久的将来，我的公司计划支持OAuth 2.0，并且我希望确保上述方案不会违反任何OAuth标准。根据我的理解，OAuth 2.0将访问令牌的验证留给了实现。我希望上面描述的临时令牌是一种访问令牌。

2. 用户关闭门户浏览器后，浏览器是否可以销毁cookie。在这种情况下，如果用户稍后打开另一个浏览器，他/她应该再次进行身份验证。

Answer 1

  

是否有基于标准的方法来实现上述方案。在不久的将来，我的公司计划支持OAuth 2.0，并且我希望确保上述方案不会违反任何OAuth标准。

你有点像回答你的问题。这种“基于标准的方法”是OAuth，IETF已在RFC 6749中记录了标准跟踪，并已被许多软件实体采用。如果您没有实施OAuth，那么您没有违反标准化规则，如果您声称已在您的系统中实施了OAuth授权，那么您将违反该标准，但显然您没有。{/ p >

  

根据我的理解，OAuth 2.0会将访问令牌的验证留给实现。

嗯，OAuth比仅仅生成访问令牌更复杂，在您请求访问令牌之前，还有一个授权授权请求。如果客户端需要扩展访问令牌的生命周期，您还可以公开令牌刷新端点。因此，OAuth授权流程

中不仅包含访问令牌请求

  

我希望上面描述的临时令牌是一种访问令牌

什么是访问令牌？由您决定如何实现访问令牌，实现细节属于您和其他任何人。您唯一需要保证的是访问令牌代表发给客户端及其范围的授权，换句话说，给定一个访问令牌，您的系统应该能够识别客户端和该客户端的范围......什么允许客户端执行，允许客户端请求哪些资源。请注意，OAuth定义了不直接转换为用户的客户端，它可能是用户，另一个系统，组件或应用程序。

  

用户关闭门户浏览器后，浏览器是否可以销毁cookie。在这种情况下，如果用户稍后打开另一个浏览器，他/她应该再次进行身份验证

当然，是的。这与OAuth完全无关，取决于客户端对访问令牌的处理方式以及存储方式。如果您的系统发出非持久性cookie，那么只要用户关闭浏览器，就会销毁浏览器会话以及cookie。所有现代Web开发技术都提供cookie管理实现，如JSP，ASP.NET，PHP等。因此，我建议将访问令牌存储在非持久性cookie中，并让您的授权服务器通过检查来检查对所有受保护资源的请求。身份验证票证/ cookie（访问令牌所在的位置）并验证访问令牌，如果访问令牌（或cookie）不存在，则拒绝该请求，因为它是对受保护资源的匿名请求。

希望它有意义