时间戳

首页 > 解决方案 > 邮递员如何在不实际重定向到 RedirectURL(callbackUrl) 的情况下完成 OAuth 2.0 流程？

react-native - 邮递员如何在不实际重定向到 RedirectURL(callbackUrl) 的情况下完成 OAuth 2.0 流程？

问题描述

我目前正在尝试使用 react native 将 MQL5 登录集成到我的移动应用程序中。

没有太多示例可以学习如何集成它。但是，我可以成功使用邮递员获取访问令牌

在此处输入图像描述

填写回调 url、client_id 和 client_secret 后，单击请求令牌按钮。它会要求我登录 MQL5，然后邮递员可以获取访问令牌，而无需实际重定向到回调 URL 页面。邮递员是如何做到这一点的？

标签： react-nativeoauthpostman

解决方案

Postman 能够根据授权流程捕获代码或令牌，因为它在内部处理请求。这与本机应用程序推荐的典型和推荐流程 ( rfc ) 不同，其中身份验证由系统浏览器处理，该浏览器将重定向视为授权端点的请求，如第一张图中所示。相反，Postman 恢复代码并使用它直接从资源服务器获取访问令牌。

  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  |          User Device          |
  |                               |
  | +--------------------------+  | (5) Authorization  +---------------+
  | |                          |  |     Code           |               |
  | |        Client App        |---------------------->|     Token     |
  | |                          |<----------------------|    Endpoint   |
  | +--------------------------+  | (6) Access Token,  |               |
  |   |             ^             |     Refresh Token  +---------------+
  |   |             |             |
  |   |             |             |
  |   | (1)         | (4)         |
  |   | Authorizat- | Authoriza-  |
  |   | ion Request | tion Code   |
  |   |             |             |
  |   |             |             |
  |   v             |             |
  | +---------------------------+ | (2) Authorization  +---------------+
  | |                           | |     Request        |               |
  | |          Browser          |--------------------->| Authorization |
  | |                           |<---------------------|    Endpoint   |
  | +---------------------------+ | (3) Authorization  |               |
  |                               |     Code           +---------------+
  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

来源：https ://www.rfc-editor.org/rfc/rfc8252#section-4.1

Postman 中的请求流程如下所示

  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  |          User Device          |
  |                               |
  | +--------------------------+  | (3) Authorization  +---------------+
  | |                          |  |     Code           |               |
  | |        Postman           |---------------------->|     Token     |
  | |                          |<----------------------|    Endpoint   |
  | +--------------------------+  | (4) Access Token,  |               |
  |   |             ^             |     Refresh Token  +---------------+
  |   |             |             |
  |   |             |             |
  |   | (1)         | (2)         |
  |   | Authorizat- | Authoriza-  |
  |   | ion Request | tion Code   |
  |   |             |             |        +---------------+
  |   |             |             |        |               |
  |   |             '--------------------->| Authorization |
  |   '------------------------------------|    Endpoint   |
  |                               |        |               |
  |                               |        +---------------+
  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
  1. Postman 将因此打开与授权端点的连接，并
  2. 发送如下所示的 HTTP GET 请求。
GET /authorize?prompt=login&response_type=code&state=<STATE>&redirect_uri=<REDIRECT_URI>&client_id=<CLIENT_ID> HTTP/1.1
Host: AUTHORIZATION_SERVER_URL
  1. 授权将以 Postman 向您显示的登录表单作为响应。
  2. 您输入您的凭据，Postman 使用您的凭据回复一个 POST 请求。
  3. 服务器发送带有 302 重定向的响应，例如：
HTTP/1.1 302 Found
Location: <REDIRECT_URI>?code=<CODE>
&state=<STATE>
  1. 现在，邮递员不再将您重定向到重定向 uri，而是使用它在对令牌端点的响应中获得的代码发送一个 POST 请求：
POST /token HTTP/1.1
Host: AUTHORIZATION_SERVER
Authorization: Basic <CLIENT_SECRET_IF_CONFIDENTIAL_CLIENT>
...
grant_type=authorization_code&code=<CODE>
&redirect_uri=<REDIRECT_URI>
  1. 授权服务器使用令牌进行响应，这是一个签名的 base64 编码的 json 对象，Postman 可以为您显示。

此处描述了整个过程：https ://www.rfc-editor.org/rfc/rfc6749#section-4.1对于不同的约束（SPA、全栈网站、原生应用程序），但它们的功能都相似。

总而言之，Postman 提供了立即获取令牌并将其嵌入的便利，并且广泛用于开发目的。然而，许多其他本地应用程序也这样做，甚至网站也会在 IFrame 中处理身份验证，这为恶意使用打开了大门，而且即使在不受信任的设置中也会训练用户输入他们的凭据。遵循建议的工作流程的安全优势之一是应用程序永远不会获取凭据，并且浏览器会强制只有重定向响应中引用的网站才能获取代码。这可以防止恶意应用程序窃取您的凭据（在上面的步骤 4 中），因为登录是在授权服务器上使用受信任的用户代理（您的浏览器）进行的。

推荐阅读