使用LinkedIn JSAPI凭据cookie对用户进行身份验证

Question

我们希望在我们的应用中实施“使用LinkedIn登录”。由于应用程序具有JS前端和基于RESt的后端，因此我们决定按照here所述交换REST API OAuth令牌的JSAPI令牌。

如果用户成功登录，前端会将带有客户端承载令牌和成员ID的凭证cookie发送到后端。在后端，我们检查具有这样的成员ID的用户是否已经存在，如果没有，我们将交换JSAPI令牌用于REST API OAuth令牌，从LinkedIn检索用户详细信息并将其存储在我们的数据库中。

现在问题是我们是否可以使用该cookie来验证每个用户对REST后端的请求。用户通过JSAPI成功登录后，cookie应在所有后续请求中自动传递给我们的后端，以便我们检查成员ID。我们错过了任何缺点吗？或者这个想法总体上是错误的？

我们是否应该通过cookie只对用户进行一次身份验证，然后发出我们自己的身份验证令牌并将其发送回客户端？

Answer 1

Cookie的工作方式通常是每次请求传递给他们所属的域。 LinkedIn正在为您的域设置凭据Cookie。

只要您在每个请求上验证这些凭据，使用其令牌作为身份验证是完全可以接受的。

我个人认为这不是一个好主意，并且更愿意验证他们的凭证一次并创建我自己的身份验证令牌以便从那里开始使用。您始终可以将该令牌设置为在某个时间点到期并重新验证LinkedIn凭据（无论如何仍将在每个请求上发送）。这限制了您使用LinkedIn查看的次数，并且应该提高应用的响应速度。

Answer 2

无论哪种方式都可以。

如果您使用LinkedIn Cookie按成员ID验证用户，则应根据所链接文档的第2部分和常见问题解答2中的每个请求验证Cookie的签名。

使用您自己的令牌可以更轻松地实施属于您的应用的帐户，并且不一定与LinkedIn相关联，假设有可能单独与其他服务连接或没有第3部分（y / IES）。仍然应该在您信任cookie中的成员ID时验证。

该文档在PHP中提供了验证示例，如果您对改进ruby版本感兴趣，我有一个shameless plug.

如果您只是登录将JSAPI令牌转换为OAuth令牌，然后不再使用JSAPI，那么您在最新评论中直接获取OAuth令牌的流程是最好的方法。如果您计划实际使用前端应用程序中的JSAPI令牌和后端的OAuth令牌，那么最好采用转换路径。