我们想在我们的应用程序中实现“使用 LinkedIn 登录”。由于该应用程序具有 JS 前端和基于 REST 的后端，因此我们决定将 JSAPI 令牌交换为 REST API OAuth 令牌，如此处所述。
如果用户成功登录，前端将带有客户端不记名令牌和成员 ID 的凭据 cookie 发送到后端。在后端，我们检查是否已经存在具有此类成员 ID 的用户，如果不存在，我们将 JSAPI 令牌交换为 REST API OAuth 令牌，从 LinkedIn 检索用户详细信息并将其存储在我们的数据库中。
现在的问题是我们是否可以使用该 cookie 来验证每个用户对 REST 后端的请求。用户通过 JSAPI 成功登录后，cookie 应在所有后续请求中自动传递到我们的后端，以便我们检查成员 ID。有没有我们遗漏的缺点？还是这个想法整体上是错误的？
我们是否应该通过 cookie 只对用户进行一次身份验证，然后发出我们自己的身份验证令牌并将其发送回客户端？
一般来说，cookie 的工作方式是在每个请求中将它们传递到它们所属的域。LinkedIn 正在为您的域设置凭据 cookie。
只要您在每个请求上都验证这些凭据，就完全可以使用它们的令牌作为身份验证。
就我个人而言，我认为这不是一个好主意，并且更愿意验证他们的凭据一次并创建我自己的身份验证令牌以从那里使用。您始终可以将该令牌设置为在某个时间点过期并重新验证 LinkedIn 凭据（无论如何，每个请求仍会发送该凭据）。这限制了您使用 LinkedIn 检查的次数，并应提高您的应用程序的响应能力。
无论哪种方式都可以工作。
如果您使用 LinkedIn cookie 通过会员 ID 验证用户，您应该根据您链接的文档的第 2 部分和常见问题解答的问题 2 验证每个请求上的 cookie 签名。
使用您自己的令牌可以更轻松地实现属于您的应用且不一定连接到 LinkedIn 的帐户，假设有可能仅与某些其他服务连接或没有第 3 部分（y/ies）。仍然应该在您信任 cookie 中的成员 ID 时进行验证。
该文档提供了一个 PHP 验证示例，如果您有兴趣改进 ruby 版本，我有一个无耻的插件。
如果您只是登录以将 JSAPI 令牌转换为 OAuth 令牌，然后不进一步使用 JSAPI，那么您在最新评论中概述的直接获取 OAuth 令牌的流程是最好的方法。如果您打算在前端应用程序中实际使用 JSAPI 令牌和在后端使用 OAuth 令牌，那么最好采用转换路线。