【问题标题】:Should my app issue it's own access tokens, when using external oauth2 provider (facebook)?在使用外部 oauth2 提供程序(facebook)时,我的应用程序是否应该发布它自己的访问令牌?
【发布时间】:2016-08-26 10:54:54
【问题描述】:

我想让用户可以在我的应用程序中使用一些外部 oauth2 提供程序 (facebook) 登录。客户端部分在移动设备上的原生应用程序中运行。

我不确定我应该更喜欢以下哪种方法?

  1. 客户端是否应该通过 facebook 通过 each 请求发送用户的访问令牌?在每个请求后端要求 facebook 验证访问令牌。后端根据验证结果进行授权,并将相应的结果返回给客户端。

  2. 如果后端要求 facebook 仅在用户登录时验证访问令牌,然后发出自己的访问令牌,将访问令牌返回给客户端,客户端将使用此访问令牌在向服务器发出请求以避免在每次请求时联系 facebook ?

我已经阅读了一些关于如何使用 facebook 实现身份验证的问题,并且大多数开发人员都在使用 B,但我没有看到任何解释为什么使用 A 好/坏?

我认为解决方案的好处:

  1. 后端不需要关心发布、刷新、验证访问令牌,因为这仅由 facebook 的授权服务器完成。
  2. 此解决方案似乎更有效,因为它不需要在每次请求时都连接到 facebook。

【问题讨论】:

    标签: security facebook-graph-api oauth-2.0 access-token


    【解决方案1】:

    Facebook 发行的安全令牌使用digital signature 签名。 API 服务器只需要访问公钥来验证签名。用户认证后完全不需要联系Facebook。

    在用户使用 Facebook 登录后发行您自己的令牌的原因可能是向令牌添加声明。但显然拥有自己的授权服务器是有代价的。由你来权衡利弊。

    如果您决定拥有自己的授权服务器,请确保不要自己编写!有像Thinktecture IdentityServer 这样的开源选项。

    【讨论】:

      【解决方案2】:

      我将投票给选项 B,这是我的解释,

      1. 您的 API 每次都必须使用某个身份验证令牌授权请求,该令牌不能是外部提供商令牌,在这种情况下,任何拥有其他提供商的访问令牌(例如:其他开发人员)的人都可以访问您的 api,基本上在那里这里没有身份验证。

      2. 当您的服务器发出访问令牌时,它很容易验证,并且可以在需要时轻松撤销(例如:在密码重置时)

      3. 在进行身份验证时,您的服务器可以完全控制颁发访问令牌,因此只需进行一次验证,而不必在调用 API 时每次都进行。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-01-15
        • 1970-01-01
        • 1970-01-01
        • 2013-08-05
        • 2011-12-11
        • 2018-12-23
        • 2012-05-04
        • 1970-01-01
        相关资源
        最近更新 更多