我想实现一个不执行传统oauth重定向的Facebook身份验证。它不能很好地与我的单页面应用程序和GraphQL API配合。
在JS端，我可以调用FB.login来触发用户登录的对话框。如果这是成功的，我收到一个包含accessToken和signedRequest的对象。
signedRequest可以在服务器上解码，它为我吐出一个code。我可以使用code和/oauth/access_token来获得accessToken。
然而，我已经从FB.login响应中获得了accessToken。所以我的问题是:是否有任何点我解码签名的请求，如果我有访问令牌这整个时间?
附加:为什么FB API首先提供签名请求，为什么oauth重定向默认转发code而不是accessToken?
可以，您可以直接在服务器上使用从客户端登录获得的令牌。
它可能是一个短期的，而服务器端登录流应该立即给您一个长期的。如果您只需要在用户在页面上活动时执行API调用，那么短时间的API调用可能就可以了。(它仍然可以通过服务器端API调用来交换一个长期存在的对象，https://developers.facebook.com/docs/facebook-login/access-tokens/refreshing)
为什么FB API首先提供签名请求
它还包含了更多的信息，这可能是有用的客户端应用程序(用户id，令牌到期，外部传递的数据在旧的"画布"类型的应用程序的情况下)，并可能节省一个额外的API调用来获得这种信息。https://developers.facebook.com/docs/reference/login/signed-request/
为什么oauth重定向默认转发代码而不是accessToken?
一般安全措施。直接包含在返回URL中的令牌很容易被嵌入在该页面上的第三方脚本窃取(广告服务器等也会不时被黑客入侵)，或者作为HTTP引用的一部分泄露。code参数需要你的应用程序的API调用的秘密交换令牌，所以如果代码以任何这样的方式泄漏，任何人得到它，不能做任何事情。