【问题标题】:Manual generating OAuth Access tokens手动生成 OAuth 访问令牌
【发布时间】:2013-07-15 09:54:49
【问题描述】:

我希望使用 OAuth 来保护某些 Web 服务。 OAuth 2 非常适合我的用例,在这些用例中,用户可能使用 API 访问他/她自己的数据或授予某人访问权限以代表他调用 API。

但是,最初的 API 用户集技术含量不高,他们不希望仅仅为了生成令牌而进行 API 调用。我正在考虑实施以下解决方案,但不确定这是否正确。

如果用户是开发者,那么

  1. 有一个他/她可以注册应用程序的屏幕。这将生成一个 API 密钥/密钥对。
  2. 要访问他/她自己的数据(对于 2 腿身份验证),有一个 UI 屏幕,用户可以在其中为他注册的应用程序生成访问令牌。他可以在表格中指定范围和持续时间。
  3. 如果他是第 3 方开发人员,则需要将他的应用程序 API 密钥传递给他需要代表其访问 API 并获取访问令牌的人。

如果用户希望其他应用程序/开发人员代表他访问 API,那么

  1. 有一个屏幕,他可以在其中输入第三方的 API 密钥、范围和授权持续时间。他可以将生成的访问令牌传递给将访问 API 的开发人员

我将使用相同的 OAuth 库来生成令牌,如果我采用了 Web 服务路线,我会使用该令牌。此外,我还可以在当前情况无法扩展或出现需求并且现有令牌仍然有效时开发服务。

【问题讨论】:

    标签: security oauth-2.0


    【解决方案1】:

    问题主要是安全问题之一。按照设计,访问令牌的持续时间不应由客户端设置。如果其他人在此期间知道了访问令牌和客户端 ID,则该用户的帐户将被盗用。通常此持续时间设置为不会很长,并且使用第二个秘密值刷新令牌来刷新当前访问令牌。令牌刷新可以在代码中自动进行,但在您的方法中需要手动完成。

    【讨论】:

    • 当然,只要不提供令牌过期选项并让它在自然流中出现,这将是微不足道的。我尝试采用这种方法的全部原因是因为客户不想仅仅为 OAuth 编写代码(或没有能力)。此外,我的 API 将在 HTTPS 上,因此获取访问令牌并非易事。不确定我是否理解有人访问客户端 ID 和访问令牌的观点,因为如果发生这种情况,无论我采取什么方法,我都会被搞砸。
    • HTTPS 是好的,只要您有处理 Oauth 的代码。但是一旦你制作了这本手册,你就不能依赖开发者来确保他只在正确的地方使用它。它可以通过电子邮件、聊天、张贴笔记等方式进行交换。加上生成的访问令牌不会过期,这只会增加随着时间的推移发生某些事情的可能性。
    猜你喜欢
    • 2013-08-09
    • 1970-01-01
    • 1970-01-01
    • 2011-12-04
    • 2020-08-10
    • 2015-04-28
    • 2016-11-24
    • 2013-02-14
    • 1970-01-01
    相关资源
    最近更新 更多