【发布时间】：2017-03-01 05:08:43
【问题描述】：
我想创建类似 Google 的单点登录应用程序，以允许我们其中一个应用程序的成员访问所有其他应用程序，而无需再次登录。
但我找不到正确的方法，我想我在 grant_type=authorization_code 方法中遗漏了一些东西，尤其是this part of the RFC 6749：
(B) 授权服务器对资源所有者进行身份验证（通过 用户代理）并确定资源所有者是否 授予或拒绝客户端的访问请求。
SSO 应用本身是一个 OAuth 客户端，具有自己的 client_id，因此当用户进行身份验证时，SSO 会为这对夫妇（SSO，用户）获取一个 access_token，并将其存储到 SSO 的会话中以供进一步使用。
因此，当客户端（“应用程序”）需要 access_token 时，它将被重定向到 SSO，该 SSO 本身将在 Authorization 标头中请求带有应用程序的 client_id 和我的 SSO 的 access_token 的授权代码，以了解要访问的用户资源。
这就是问题所在：我的 SSO 的 access_token 是为 SSO 的 client_id 而不是应用程序的 client_id 创建的。因此，使用为一个客户端生成的 access_token 来识别授予另一个客户端访问某些资源的用户似乎是 hacky/无效的。
这是一个（简化的）模式，用于更好地理解流程：
01 User Client SSO OAuth Server 01
02 + + + + 02
03 | | | | 03
04 | User requests resource | | | 04
05 | +-------------------------> | | | 05
06 | | | | 06
07 | | Client redirects to SSO | | 07
08 | | +-----------------------> | | 08
09 | | | | 09
10 | | | SSO authenticates user | 10
11 | | | +------------------------> | 11
12 | | | | 12
13 | | | token stored on SSO side | 13
14 | | | <------------------------+ | 14
15 | | | | 15
16 | | | SSO requests grant code | 16
17 | | | +------------------------> | 17
18 | | | | 18
19 | | authorization code returned to client | 19
20 | | <----------------------------------------------------+ | 20
21 | | | | 21
22 | | authorization code exchanged for an access_token | 22
23 | | +----------------------------------------------------> | 23
24 | | | | 24
25 | | access_token returned to client | 25
26 | | <---------------------------------------------------+ | 26
27 | | | | 27
28 | user can access resource | | | 28
29 | <-------------------------+ | | | 29
30 + + + + 30
在第 10 行，我们假设用户未登录，因此用户在 SSO UI 上输入其凭据，然后 SSO 将使用自己的 client_id 和 grant_type=password 调用授权服务器以获取 access_token。
在第 13 行，access_token 给了 SSO，它是一个 access_token，将 user_id 与 SSO 的 client_id 绑定在一起，这样我们在一个集中的应用程序中登录了用户，我们不再需要登录他了。
在第 16 行，一旦用户单击“授权”以授予客户端访问资源，SSO 会代表用户向 OAuth 服务器请求授权代码，授权标头中包含 SSO 的 access_token 以识别该用户。
在我的流程中，SSO access_token 为其他客户端识别用户，我认为它无效。有人可以给我一些建议吗？
【问题讨论】：
标签： api security oauth oauth-2.0 single-sign-on