【问题标题】:Facebook oauth flow advantage over direct access tokenFacebook oauth 流量优势优于直接访问令牌
【发布时间】:2016-12-08 01:01:54
【问题描述】:

Fb 身份验证过程似乎是:

  • 在 fb 身份验证页面上打开一个弹出窗口,如果授予权限,它会使用代码 ping 我的服务器
  • 然后我可以使用我的应用程序密码(来自我的服务器)将该代码换成访问令牌

这个获得的访问令牌最终会过期,然后我只需要用户再次登录以提供更新的访问令牌。

但是在带有 FBSDKLoginKit 的 iOS 上,我可以直接获取访问令牌,而无需涉及服务器。那么第一个更复杂的流程有什么意义呢?为什么 fb 不直接向 Web 客户端(可以将其中继到我的服务器)发出访问令牌?为什么 Web 客户端和移动客户端看起来不一样?

【问题讨论】:

    标签: facebook authentication oauth-2.0


    【解决方案1】:

    这在 OAuth 2.0 标准的breakdown of client types 中得到了解决:

    基于用户代理的应用程序

    基于用户代理的应用程序是一个公共客户端,其中客户端代码从网络服务器下载并在资源所有者使用的设备上的用户代理(例如网络浏览器)中执行。协议数据和凭证对资源所有者来说很容易访问(并且通常是可见的)。由于此类应用程序驻留在用户代理中,因此它们可以在请求授权时无缝使用用户代理功能。

    本机应用程序

    本机应用程序是在资源所有者使用的设备上安装和执行的公共客户端。资源所有者可以访问协议数据和凭证。假设可以提取应用程序中包含的任何客户端身份验证凭据。 另一方面,动态发布的凭据(例如访问令牌或刷新令牌)可以获得可接受的保护级别。至少,这些凭据受到保护,不受应用程序可能与之交互的恶意服务器的影响。在某些平台上,可能会保护这些凭据免受驻留在同一设备上的其他应用程序的影响。 [强调我的]

    因此,显然 Facebook 正在遵循此建议并假设本机应用程序(而不是 Web 应用程序)可以保护访问令牌。

    【讨论】:

      猜你喜欢
      • 2017-08-30
      • 1970-01-01
      • 2020-05-22
      • 2012-05-28
      • 2011-07-02
      • 1970-01-01
      • 1970-01-01
      • 2019-07-23
      • 1970-01-01
      相关资源
      最近更新 更多