Insomnia: [Improvement] Better OAuth 2.0 redirect handling

[gschier]

This issue is a result of the discussion happening on #404

Improvement 1 – Also intercept redirects

The current implementation of the auth window only looks at window location changes. So, if the auth form redirects to a URL that then redirects somewhere else, Insomnia will only see the final URL in the chain – the one that ends up getting loaded by the browser window.

It looks like Electron BrowserWindow has an API that allows inspecting redirects directly.

Improvement 2 – Option to enable strict redirect_uri matching (currently the default)

Because of #396, Insomnia makes sure the redirect URL is prefixed with the redirect_uri defined in the OAuth settings. However, this has proved to cause problems for some users. It's also possible that Improvement 1 will solve this problem instead.

[Kadrei]

Is there any timeline/update on this issue as it prevents us from using this REST-Client because we cannot use it with out current OAuth2 Integration as it does not see the token because of the redirect issue.

[gschier]

I can't give a definite timeline but I'll try to fix it soon.

@Kadrei Can you describe what exactly is causing the issue for you? I just want to make sure I'm fixing the correct thing.

[Kadrei]

As far as I can debug Insomnia does miss a redirect that happens and therefor does not extract the key from the url.

[gschier]

Can you include output from View > Toggle DevTools > Console?

[Kadrei]

[ga] Event Request, Activate, Sidebar
[ga] Google analytics tracking disabled. Not sending
[ga] Non-interactive Notification, Shown, upgrade-support
[ga] Google analytics tracking disabled. Not sending
[oauth2] Loaded "https://<host2>.dev.abcdef.tld/oauth2/v1/auth?response_type=code&client_i…session.close%20scopehost.session.create%20scopehost.session.get&state=%2F"

form redirect happens here

[oauth2] Ignoring URL "https://<host>.dev.abcdef.tld/main/#/". Didn't match /https:\/\/<host>\.dev\.abcdef\.tld\/auth\/login.*(code=|error=)/i
[oauth2] Ignoring URL "https://gate.dev.abcdef.tld/oauth2/v1/auth?response_type=code&redirect_uri=h…ment.*+discovery+&state=%2F". Didn't match /https:\/\/<host>\.dev\.abcdef\.tld\/auth\/login.*(code=|error=)/i

[gschier]

Hmm, I don't see a code querystring parameter in either of those URLs that were ignored. At a minimum, this code parameter should be present in the final URL. Do you know why this may be?

It's very difficult to figure out what's wrong without knowing the details of your server's authentication flow. Any details you can provide would help a lot.

[Kadrei]

Because the url with code is not recognized as it is accompanied with a 307 http status code.

[gschier]

Got it. So let me know if this is correct (I want to build a test case).

1. Form loads at some authorize URL app.com/auth
2. User submits form
3. Server validates request and redirects user to app.com/redirect?code=123
4. Redirect URI then redirects with 307 to app.com/some/other/url
5. Insomnia loads HTML for app.com/some/other/url

Since Insomnia never actually loads the URL in step 3, it fails to detect the URL and grab the code.

[Kadrei]

Yes, this should be it:

1. GET authorizeurl

2. JS POST-Call with formdata

3. JS Code gets a Response with a redirectUri-field which has the ?code=...

4. GET on the received url (redirectUri) returns a 307 which then redirects us to another url without the code

This is basically described in the RFC

So as far as i can see - Insomnia does not see the redirectUri which returns a 307 and therefor misses the ?code=... part.

Tests with paw and postman shows that they have no problem with it.

[unff]

Just to add another use-case to this fire:

eBay's OAuth 2.0 implementation for their new REST APIs uses a custom redirect_uri that is neither a URI nor optional . There's no second redirect, it just doesn't match the expected values.

Pretty sure Improvement 1 will cover this use case, but thought I'd chime in all the same. Fiddler screenshot attached.

[bjeanes]

Weighing in here as also affected.

In my case, I think there is the OAuth2 provider performs an internal redirect before redirecting back to the application callback. Then the callback URL performs its own token fetching and redirects into a logged in state.

The logs for my interaction only have the following two noteworthy lines:

```
[oauth2] Loaded "hhttps://test-account.cochrane.org/oauth2/auth?response_type=code&client_id=covidence&redirect_uri=https%3A%2F%2Fstaging.covidence.org%2Foauth%2Fcallback&scope=person%20document"
bundle.js:45462 [oauth2] Ignoring URL "https://staging.covidence.org/reviews/active". Didn't match /https:\/\/staging.covidence.org\/oauth\/callback.*(code=)/i
````

The /reviews/active path is several redirects after a successful login, during a normal authentication flow.

[Logifire]

I have the issue with the Blizzard API (https://develop.battle.net/documentation/api-reference/oauth-api), it's my first time trying OAuth, and couldn't understand where the "code" was. It's a query parameter of the redirect back to the original site - but Insomnia didn't show it in the timeline.

Could also be nice showing the URL the preview window is displaying - after redirects, that's how I figured it out, using a normal browser.

EDIT: I was a bit to fast, I thought this was blocking me, I didn't used the built in OAuth 2, I was trying to follow the flow (see link above) doing individuel requests, and couldn't find the "authorization code".

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.