如何使用访问令牌转换OAuth代码

Question

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

1. 用户被重定向到 http://some-service.com/login
2. 用户成功登录并重定向到某个目的地http://some-destination.com.在此步骤中,通常会有一个code请求附带的参数.所以实际的URL看起来像http://some-destination.com?code=CODE123
3. 我需要用来CODE123请求一个access_token可以用来授权我未来的API调用的东西.要做到这一点,有一个通常看起来像这样的端点(我使用Nylas作为示例,但应该足够通用):

正如你所看到的,它要求我从上面张贴代码(CODE123)连同client_id与client_secret这样的:http://some-service.com/oauth/token?code=CODE123&client_secret=SECRET&client_id=ID.作为回应,我得到一个access_token看起来像TOKEN123我可以使用它来进行API调用.

题

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

Answer 1

您可能知道，该问题描述了最常见（通常也是更安全）的 OAuth “授权代码”流程。需要明确的是，这里是此流程中步骤的近似值：

\n

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

\n

\n

在第 2 步之前，一切都发生在客户端。但在第 3 步中，我需要有 client_id 和 client_secret。我认为将这些值存储在客户端不是一个好主意。这是否意味着我需要一个具有这两个值的后端服务器[？]

\n

\n

您是对的，将这些值存储在客户端应用程序中当然不是一个好主意。这些值\xe2\x80\x94尤其是客户端密钥\xe2\x80\x94必须放置在服务器上以保护应用程序的数据。用户\xe2\x80\x94 以及客户端应用程序\xe2\x80\x94 永远不应访问这些值。

\n

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

\n

\n

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

\n

\n

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

\n

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

\n

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

\n

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

\n

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

\n