使用第三方网站进行OAuth2 / OIDC授权代码流程-了解最终步骤

Question

我有一个站点有望使用第三方服务登录（通过使用OAuth2和OIDC）。我了解其中90％的过程，但未能达到我认为的最后一步。我将在此处介绍这些步骤，可能有人会帮助我填补这些空白。在我的设置中，资源服务器和授权服务器是同一台机器。

这是我所设想的登录过程。

1. 用户来到我的网站（我们称其为站点A）并点击登录
2. 他们被重定向到身份验证站点（站点B） 输入他们的用户名/密码。
3. 假定凭据正确，然后使用身份验证代码将其重定向回站点A。
4. 站点A接受此身份验证代码，并在反向通道中与站点B进行通信 再次要求将代码交换为令牌。
5. 站点B提供对站点A（而不是最终用户，服务器）的访问令牌
6. 站点A然后再次与站点B通信（在这种情况下，资源服务器和身份验证服务器相同）并获取相关的用户详细信息。

因此，用户已通过身份验证，我们知道他们的主张，但是，在上述情况下我没有得到的是网站A如何知道我（最终用户）的身份。

我从未登录站点A，因此大概没有设置cookie。基本上，我去过该站点，已重定向到另一个站点，在那里登录，然后被重定向回站点A，但是在最后一个重定向中是否设置了cookie以标识我？

我已经在网上阅读了大量有关此内容的信息，但没有找到明确的答案。

此外，我是否认为在访问授权码流中访问令​​牌永远不会到达用户而是驻留在应用程序服务器上，这是正确的吗？

Answer 1

OpenID Connect身份验证服务器提供userinfo endpoint，站点A可以使用该Request获取有关授权访问令牌（或授权代码）的用户的信息。为了使身份验证提供程序（站点B）能够执行此操作，它需要保持令牌与其用户之间的关联。因此，没有用于此目的的cookie。

您对验证码流程是正确的-访问令牌位于后端-无需将其发送给前端/用户。

要使保留在SiteA后端的令牌与浏览器的后续请求配对，您有几种选择：

• 您可以将后端会话与cookie一起使用，这非常简单，因为大多数后端框架都对它具有内置支持。 cookie随每个请求自动发送，令牌可以存储在会话对象中。如果需要群集，此解决方案可能难以扩展。
• 您可以创建自己的会话实现-通过使用cookie或REST API上预期的某些标识符作为Authorization HTTP标头值。后端会话数据可以保存在某些分布式存储中，例如Hazelcast或数据库。会话标识符可以采用签名的JWT的形式，因此您可以将用户信息保留在其中。

Answer 2

如果您really想知道该用户在SiteA上，则该用户必须是SiteA自己的用户数据库中的用户。如果SiteA不仅是SiteB API的代理，而且拥有自己的用户，权限和功能，那么这是有道理的。

要弄清楚用户在SiteA上的身份，您需要将所有SiteA的用户与Auth Server的用户进行匹配。

第1部分。将现有用户导入Auth Server

如果您控制Auth Server，请将所有当前用户导入其用户数据库。他们每个人都有主题ID（身份验证服务器端的ID）。将这些ID复制回SiteA的db中的相应用户：SiteA的User表将具有新列，例如： userid，user_name，user_last_name，user_auth_id（新列）

如果您不能导入所有用户，则会变得很复杂。我能想到的唯一方法是：您必须两次登录这些用户-一次登录OIDC提供程序，一次登录SiteA，然后将SiteA的用户与OIDC用户关联。

第2部分。将传入用户与SiteA中的内部用户进行匹配

在OIDC服务器的成功响应中，您将获得ID令牌。它包含具有用户主题ID的sub个声明。完成后，您将需要在内部数据库中进行查找并找到相应的SiteA用户。如果找不到，请在SiteA创建一个新用户（如果所有现有用户均已导入）

一旦您知道用户是谁，就可以像平常一样将其登录到SiteA（例如，给他们一个cookie）。