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

Question

在我的例子中，公司 B（域 B）托管了一个门户，该门户具有指向我的 Web 应用程序（域 A）的链接。如果用户单击门户上的超链接到我的域，他/她应该会自动登录到我的应用程序。

我无法改变的现有政策：

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

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

当用户登录门户时，门户公司将生成一个临时令牌 (UUID)，并将其作为查询参数附加到我的 Web 应用程序的超链接。当用户单击我的 Web 应用程序的超链接时，我的 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 授权，那么您显然没有违反标准化规则。

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

好吧，OAuth 比仅仅生成访问令牌要复杂一些，在您请求访问令牌之前需要授权授权请求。如果客户端需要延长访问令牌的生命周期，您还可以公开令牌刷新端点。因此，OAuth 授权过程中涉及的不仅仅是访问令牌请求

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

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

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

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

希望有意义