Postman 邮递员如何处理本地主机OAuth 2重定向？

当使用邮递员通过授权码获取访问令牌时，我需要输入的字段之一是回调URL，也就是向授权端点发出请求时的重定向URI查询参数。我知道这个URL需要在OAuth提供程序中注册/列入白名单，但我的问题是，当它基于本地主机时，postman实际上如何处理/截获该请求/重定向回？例如，如果我已经有一个本地服务器在http://locahost:8090，我叫邮递员用http://localhost:8090 对于该回调，邮递员如何最终看到该请求/重定向回（将身份验证代码交换为访问令牌），而不是我的本地web服务器处理该请求；DR:Postman在处理响应时基本上忽略回调URL

长话短说

它确实需要它，但只是为了请求。正如您所说，它需要是正确的——与IdP客户端应用程序配置完全匹配——但仅此而已

Postman只是帮助您获取令牌，它不需要将其提供给消费应用程序，这是重定向URL的全部要点—客户端应用程序和OAuth客户端应用程序知道的静态路径，确保恶意网站/中介不会滥用重定向流偷取令牌

由于它不适用于互联网上的浏览器，邮递员可以忽略重定向。一旦IdP用令牌响应，那么，就邮递员而言，就可以走了。它可以将令牌保存在本地令牌存储中，并使用它发出API请求

隐式流

此设置用于从Okta端点获取令牌：

当我点击“请求令牌”时，邮递员发出如下请求：

GET https://exampleendpoint.okta.com/oauth2/default/v1/authorize?nonce=heythere&response_type=token&state=state&client_id={the_client_id}&scope=profile%20openid&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fimplicit%2Fcallback

邮递员弹出浏览器向

/authorize

端点发出此请求，IdP在该端点处创建令牌（如果浏览器已经有cookie），或执行各种重定向以验证用户身份，然后创建令牌

在该流结束时，邮递员将从包含令牌的IdP接收302（在位置报头上）。该重定向的目标是在IdP中配置的重定向URL：

302 
Location: http://localhost:8080/implicit/callback#access_token=eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.{the_rest_of_the_token}&token_type=Bearer&expires_in=3600&scope=profile+openid&state=state

此时，邮递员从#access_token参数中抓取令牌，就可以开始了

验证代码流

认证代码流有两种风格：

• 验证代码（经典）
• 验证码+PKCE

身份验证代码流被认为比隐式流“更好”，因为它需要流程中的第二步来获取访问令牌。点击authorize，它会给客户端一个代码，然后将代码交换为令牌。这个令牌代码为服务器端组件提供了更多的机会来做更多的事情——额外的检查、丰富令牌和其他各种事情

问：为什么有两个身份验证代码流？ 答：问题是它需要一个服务器端组件，而许多SPA和/或移动应用程序都不想托管这个组件。接收代码并获取令牌的端点必须维护凭据（客户端id和客户端机密），这是IdP在创建令牌时所需的凭据。PKCE是一个扩展，它消除了对受信任服务器的要求。它向IdP记住的/authorize调用添加计算出的哈希，然后在对/token的后续调用中，客户机提供哈希的源值。服务器执行相同的计算，检查它是否与原始请求相同，然后确定它没有向坏人分发令牌

使用PKCE验证代码

就重定向而言，这与隐式完全相同。但是对于请求，它需要发出第二个请求来交换代码以获得令牌。这里的主要区别是

• 访问令牌URL，用于发送代码和获取响应令牌
• 代码质询和验证器，它们是PKCE生成和计算哈希的要求

现请求如下：

到达/授权

邮递员将弹出浏览器（如果需要，IdP将通过登录重定向）

最终的代码响应也是302，但是

位置

头包含代码而不是令牌：

location: http://localhost:8080/implicit/callback?code=J3RlQqW122Bnnfm6W7uK&state=state

因此，现在客户端需要调用“访问令牌URL”字段中定义的端点来获取令牌：

POST https://exampleendpoint.okta.com/oauth2/default/v1/token
Body:
grant_type: "authorization_code"
code: "J3RlQqW122Bnnfm6W7uK"
redirect_uri: "http://localhost:8080/implicit/callback"
code_verifier: "Fqu4tQwH6bBh_oLKE2zr0ijArUT1pfm1YwmKpg_MYqc"
client_id: "{client_id}"
client_secret: ""

响应是一个很好的老200，它没有重定向-authorize调用将客户端发送回最终的重定向登录页，POST只是一个普通的请求，带有响应上的令牌

{"token_type":"Bearer","expires_in":3600,"access_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.*******","scope":"profile openid","id_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.********"}

---

因此，当浏览器窗口弹出“邮递员”时，它能够检测到发生的重定向？因此，在授权码授予的情况下，它是否检测到代码将要发生的重定向，从而停止重定向，从URL获取代码，然后邮递员直接交换代码+密码以获得令牌？是的，这就是为什么它会弹出隐式和授权码流的浏览器。他们需要一个完整的浏览器，因为IdP身份验证依赖于Cookie，如果您没有说Cookie，IdP将启动浏览器重定向以完成身份验证。这一切都发生在初始GET to/authorize的上下文中。身份验证代码稍有不同，我将添加到答案中，因为我将在这里用完字符。。

{"token_type":"Bearer","expires_in":3600,"access_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.*******","scope":"profile openid","id_token":"eyJraWQiOiJxOGRmTGczTERCX3BEVmk4YVBrd3JBc3AtMFU1cjB6cXRUMFJveFZRUVVjIiwiYWxnIjoiUlMyNTYifQ.********"}