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

在我的例子中，公司B（域B）拥有一个门户，它有到我的web应用程序（域a）的链接。如果用户单击“我的域”门户上的超链接，他/她应自动登录到我的应用程序

我无法更改的现有政策：

用户还可以通过提供用户id/密码直接登录到我的域，而无需通过门户

此外，现有的公司用户资源调配政策是，即使用户通过公司B的门户登录，他们也首先需要在我的公司拥有一个用户帐户。因此，用户将拥有门户公司和我的公司的帐户 鉴于这些限制，我的计划是提供从门户的自动登录

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

当用户注销门户应用程序时，门户服务器将以预先指定的URL向我的web应用程序发出Https请求，以注销用户。因为它是双向SSL，所以注销url受到保护

我的问题如下：

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

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

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

你好像已经回答了你的问题。这种“基于标准的方法”是OAuth，它是IETF在年记录的标准跟踪方法，并已被许多软件实体采用。如果您没有实施

OAuth

，那么您没有违反标准化规则，如果您声称在您的系统中实施了

OAuth

授权，那么您将违反标准化规则，而您显然没有

根据我的理解，OAuth2.0将访问令牌的验证留给实现

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

OAuth

授权过程中涉及的不仅仅是访问令牌请求

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

什么是访问令牌？如何实现访问令牌取决于您，实现细节属于您而不是其他人。您需要保证的唯一一件事是，访问令牌表示颁发给客户机的授权及其范围，换句话说，给定一个访问令牌，您的系统应该能够识别客户机和该客户机的范围……客户机可以做什么，客户机可以请求什么资源。请注意，

OAuth

定义的客户端不能直接转换为用户，它很可能是用户、另一个系统、组件或应用程序

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

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

---

希望它有意义

Leo在隐式授权授予中，对话是在客户端和授权服务器之间进行的。在这种情况下，客户端和授权服务器都是门户公司，也就是Outside my web app。一旦授权服务器发出访问令牌，我的应用程序就会出现在这里。我的web应用程序接收一个访问令牌，正如您所说的，访问令牌格式取决于实现。收到访问令牌后，我的web应用程序将使用授权服务器验证令牌，授权服务器同样不符合oauth规范。那么我在哪里违反了oauth规范？抱歉，我仍然无法看到您的web应用程序在哪里从门户请求授权。在OAuth中，一方不能同时扮演两个角色（客户机和服务器），并且不存在隐式授权授予，因为授权授予是由c显式请求的