时间戳

首页 > 解决方案 > 了解 OAuth2 的流程

oauth-2.0 - 了解 OAuth2 的流程

问题描述

我是 OAuth2 的新手，我正在尝试了解整个流程。对于上下文，我正在考虑制作一个 Web 仪表板，用户可以在其中通过 Discord 的 OAuth2 API 登录。

根据我目前的理解，这就是我认为流程的工作方式：

  1. 用户访问我的网站并单击登录链接
  2. 我的网站使用我的客户端 ID和查询字符串中的重定向 URL #1将它们重定向到 Discord
  3. Discord 在重定向 URL #1处将它们重定向回我的站点，并在查询字符串中使用授权代码
  4. 我的站点使用此授权代码以及我的客户端 ID、客户端密码和重定向 URL #2，使用所有这些从 Discord获取访问令牌和刷新令牌
  5. 如果我确实获得了访问令牌，则意味着用户现在已“登录”（授权码有效）
  6. 我的网站最终将用户重定向到一个页面，现在可以使用access token向 Discord 的 API 发送请求，同时保存access token和refresh token。举个例子，假设页面声明了他们的 Discord 用户名

我正在从本指南中学习，令我困惑的是本指南中的这段代码片段。在第 5 行，它在查询字符串中提供了上面提到的重定向 URL #2 。我不确定它是干什么用的。

此外，我不太确定一旦获得访问令牌后如何继续。如果多个用户登录，我手头会有多个访问令牌。假设用户想再次访问该页面，我如何唯一标识他们并知道使用哪个访问令牌向 Discord 的 API 发送请求？（对于这个例子，请求会给我他们的用户名，我会在页面上显示）

是的，我可能有很多概念错了。任何澄清将不胜感激！

编辑：我对此进行了更多研究，并在此处找到了更好的指南。

对于我关于第二个重定向 URL 的问题，官方文档redirect_uri中的示例在同时进行访问令牌和刷新令牌交换时指定了一个。但是，这个新指南不需要他们的访问令牌交换。也许他们错过了？正如另一个堆栈溢出问题所说：

作为一项附加的安全措施，服务器应验证此请求中的重定向 URL 是否与此授权代码的初始授权请求中包含的重定向 URL 完全匹配。如果重定向 URL 不匹配，服务器将拒绝请求并返回错误。

我想这意味着在第一次访问令牌交换之后，任何刷新令牌交换或带有访问令牌的直接 API 请求都需要与redirect_uri所述第一次访问令牌交换的原始内容相匹配。所以我应该只使用一个redirect_uri，并且刷新令牌交换/API请求实际上并不使用redirect_uri，而是用于进一步的安全性。

至于整个登录过程，似乎我必须将获得的访问和刷新令牌链接到用户会话，为此我将研究使用此护照策略passport-discord。然后，一旦会话到期，我将丢弃这两个令牌，他们将不得不再次单击登录，但我可以使用此prompt选项：

prompt 控制授权流程如何处理现有授权。如果用户先前已使用请求的范围授权您的应用程序并且提示设置为同意，它将要求他们重新批准他们的授权。如果设置为 none，它将跳过授权屏幕并将它们重定向回您的重定向 URI，而不请求他们的授权。

从那里我想我只是存储与该用户关联的新访问和刷新令牌。

如果能指出我思考过程中的任何错误，我将不胜感激！

标签： oauth-2.0discord

解决方案

Cloud 先生，您的总结对我来说似乎不错 - 值得澄清您是在开发 SPA 还是（旧）具有服务器端的 Web 应用程序。最常见的第一个是无 cookie，而第二个将刷新令牌存储在 cookie 中。关键是要了解 OAuth 消息工作流程是什么样的。对于 SPA 和 API，我的这篇文章可能会帮助您阐明您想要什么：https ://authguidance.com/2017/09/26/basicspa-oauthworkflow/ 很 高兴回答任何后续问题..

推荐阅读