【问题标题】:oAuth 2.0 - Acting on behalf of the useroAuth 2.0 - 代表用户行事
【发布时间】:2014-04-26 02:34:17
【问题描述】:

我是 oAUth2 的新手,我正试图弄清楚一些事情。

我了解 oAuth2 涉及的基本原则,但我不确定如何在我的情况下实施它。

我正在编写一个代表用户自动执行手动过程并执行一些任务(更新/请求状态...等)的应用程序。我们连接的 API 使用 oAuth2 来授予我们的应用程序权限。我们计划让用户在我们创建新帐户时授予我们的应用程序权限。

我了解用户将请求提供给我们的应用程序的身份验证代码。然后我们的应用程序将使用身份验证代码生成访问令牌。

我们只想这样做一次。然后充当用户发送和接收通知,而无需让用户使用其凭据登录服务。

由于身份验证代码和身份验证令牌过期,我不确定如何在不必存储用户凭据来获取身份验证代码的情况下实现这一点。我猜这是一个常见的场景。

我需要做什么才能完成我想要完成的事情?

【问题讨论】:

    标签: authentication oauth oauth-2.0


    【解决方案1】:

    您可以使用 RefreshToken 获得一个新的 AccessToken,前提是 Authorization Server 提供。

    如果未提供,我会联系 Api 提供商,您永远不应该存储用户凭据。事实上,如果 OAuth 协议作为客户端被很好地实现,那么您甚至应该永远无法获得客户端凭据。当用户必须登录时,您应该将用户重定向到授权服务器,用户应该在那里登录,然后授权令牌应该由授权服务器重定向到您的应用程序。

    另请参阅 OAuth 2.0 规范中有关刷新令牌的说明:

    刷新令牌是用于获取访问令牌的凭据。刷新 令牌由授权服务器颁发给客户端,并且是 用于在当前访问令牌时获取新的访问令牌 失效或过期,或获取额外的访问令牌 具有相同或更窄的范围(访问令牌可能具有更短的 生命周期和少于资源授权的权限 所有者)。颁发刷新令牌是可选的,由 授权服务器。如果授权服务器发出刷新 令牌,在颁发访问令牌时包含它

    注意

    如果您使用 RefreshToken 请求新的 AccessToken,并且响应包含新的 RefreshToken,则应覆盖当前保存的 RefreshToken。换句话说,您应该始终使用您收到的最新的RefresthToken。

    【讨论】:

    • 同意!好答案。刷新令牌是这里的答案。加:永远不要存储用户的信用!
    • @JosVinke - 我们正在获取刷新令牌。所以,我假设访问令牌是短暂的,而刷新令牌是长期存在的。这正是我想知道的。
    • @esquire 是的,没错。一些实现是不同的,例如 Instagram 确实使用长寿命的访问令牌。
    猜你喜欢
    • 2015-07-25
    • 2013-07-03
    • 1970-01-01
    • 1970-01-01
    • 2016-08-28
    • 2015-01-14
    • 1970-01-01
    • 1970-01-01
    • 2014-11-30
    相关资源
    最近更新 更多