Postman uses the wrong OAuth code under certain conditions

[mamacdon]

Describe the Issue
I'm using Postman to get OAuth tokens from Auth0.com. When I use one of Auth0's social-login options (for example Facebook), Postman gets an error.

Note: this bug might sound specific to Auth0, but I think it applies more broadly, whenever:

• You have "nested" OAuth transactions in play: i.e. your authorization server is brokering access to other IDPs, using OAuth.
• Some of those OAuth transactions have redirect_uris containing the same hostname.

Steps to Reproduce

1. Configure a new token using the settings shown in the screenshot.
2. Click "Get New Access Token". My Auth0 login page opens in an embedded browser.
3. I select the Facebook option, and enter my Facebook creds. (This begins a "nested" OAuth transaction between Auth0 and Facebook).
4. Postman fails with an error.

Screenshots or Videos

movie.mp4

Environment Information

• Platform Type: native app
• Postman Version: 8.1.0
• Operating System: Mac OS X

Additional Context

In the video I posted, there are two OAuth transactions happening: Postman ↔️ Auth0 (T1), and then Auth0 ↔️ Facebook (T2). There are therefore two different redirect_uris and two different code params that will pass through the browser. The root of this bug is that Postman mistakenly intercepts the code param from T2, when it's supposed to get the one from T1.

T1:

• Token endpoint: https://dev-oq-ns8vg.us.auth0.com/oauth/token
• Redirect URI: com.myapp://dev-oq-ns8vg.us.auth0.com/cb

T2:

• Redirect URI: https://dev-oq-ns8vg.us.auth0.com/login/callback

What triggers the bug is that both transactions' redirect URIs contain the same hostname, although they are different URLs. Postman seems to be doing some "loose" matching here, which causes it to take the code param from T2 and attempt to use it to get T1's token.

This is demonstrated at the end of the video I posted: note how Postman has intercepted the code from T2's redirect (https://dev-oq-ns8vg.us.auth0.com/login/callback?code=…), and used it to call T1's token endpoint with T1's redirect URI. This is wrong. The correct behavior would be to wait until a code param is provided to T1's redirect URI.

[jaap3]

Getting hit by this as well. In my case this is what should happen (loosly):

• Authentication request (www.example.com/authorize?redirect_uri=www.example.com/auth/callback)
  • Redirects to login page (accounts.example.com/login) (user login)
    • Redirects to OIDC callback (www.example.com/oidc/callback) (application session is created)
      • Redirects to www.example.com/auth/callback

Postman intercepts the initial OIDC callback (which is supposed to be handled by the application) and breaks the flow.

I am able to work around this by creating a client with an off-site callback url, but that's not ideal.