如何使用访问令牌

时间:2017-11-18 20:26:18

标签: oauth

想象一下,您正在通过标准的OAuth2流程来检索某些第三方API的access_token。这是通常的过程。

  1. 用户被重定向到http://some-service.com/login
  2. 用户成功登录并重定向到某个目标http://some-destination.com。在此步骤中,通常会有一个code参数随请求一起提供。因此,实际网址看起来像http://some-destination.com?code=CODE123
  3. 我需要使用CODE123来请求可用于授权我未来API调用的access_token。要做到这一点,有一个通常看起来像这样的端点(我使用Nylas作为示例,但应该足够通用):
  4. enter image description here

    正如您所看到的,它要求我将上面的代码(CODE123)与client_idclient_secret一起发布,如下所示:http://some-service.com/oauth/token?code=CODE123&client_secret=SECRET&client_id=ID。作为回复,我得到的access_token看起来像TOKEN123,我可以用它来进行API调用。

    问题

    直到第2步,一切都发生在客户端。但在第3步中,我需要client_idclient_secret。我不认为在客户端存储这些值是个好主意。这是否意味着我需要一个具有这两个值的后端服务器,我的后端应该将CODE123转换为TOKEN123并将其交给客户端?

1 个答案:

答案 0 :(得分:3)

您可能知道,该问题描述了最常见的(通常是更安全的)OAuth "Authorization Code" flow。需要说明的是,这里有一个近似的流程步骤:

  1. 用户表示他们希望为我们的应用程序授权资源(例如,通过单击按钮)
  2. 应用程序将用户重定向到第三方登录页面,用户登录该页面并选择要授予访问权限的资源
  3. 第三方服务使用授权码将用户重定向回我们的应用程序
  4. 我们的应用程序使用此代码及其客户端ID和密码来获取访问令牌,使应用程序能够代表用户仅针对用户允许的资源发出请求
  5.   

    直到第2步,一切都发生在客户端。但是在第3步中,我需要有client_id和client_secret。我不认为将这些值存储在客户端是个好主意。这是否意味着我需要一个具有这两个值[?]

    的后端服务器

    您是正确的,将这些值存储在客户端应用程序中肯定 这些值 - 尤其是客户机密码必须放置在服务器上以保护应用程序的数据。用户 - 因此,客户端应用程序 - 永远不应该访问这些值。

    服务器使用其客户端ID和密码以及授权代码来请求用于API调用的访问令牌。服务器可以存储它接收的令牌,以及可以在将来使用的可选刷新令牌来获取新的访问令牌,而无需用户再次明确授权访问。

      

    ...我的后端应该将CODE123转换为TOKEN123并将其交给客户端吗?

    至少,我们的服务器应处理授权流以请求访问令牌,然后仅将该令牌传递回客户端(通过安全连接)。

    但是,此时,客户端应用程序(以及该客户端的用户)负责访问令牌的安全性。根据我们应用程序的安全要求,我们可能还想添加一个层来保护来自客户端的访问令牌。

    服务器端应用程序从第三方服务获取访问令牌后,如果我们将访问令牌传递回客户端,则客户端计算机上运行的恶意软件或未经授权的人员可能会从中获取访问令牌客户端,然后攻击者可以通过授予我们的应用程序的权限来检索或操纵用户的第三方资源。对于许多OAuth服务,访问令牌与客户端无关。这意味着拥有有效令牌的任何人都可以使用令牌与服务进行交互,并说明为什么我们的应用程序只应请求用户授权时所需的最小访问范围。

    为了更安全地代表用户进行API调用,客户端应用程序可以向我们的服务器发送请求,而服务器又使用它获得的访问令牌与第三方API进行交互。通过此设置,客户端无需知道访问令牌的值。

    为了提高性能,我们可能希望在服务器上缓存访问令牌,以便在其生命周期内进行后续API调用。我们可能还想加密令牌,如果我们将它们存储在应用程序的数据库中 - 就像我们的密码一样 - 因此在数据泄露的情况下不能轻易使用令牌。