[Question] How does the "OAuth 2.0" dialog work, and how do I diagnose failure?

[seh]

Overview

• Insomnia Version: 5.7.0.911
• Operating System: macOS Sierra, version 10.12.16
• Summary: It's not clear from any documentation I've found—nor from playing with Insomnia itself—how the "OAuth 2.0" authentication dialog works (using the "Authorization Code" grant type).

I have values for all the editable fields, but the "redirect URI" field confuses me. Does my HTTP server need to be listening at that URL? There's a tooltip on the corresponding label:

Insomnia will intercept this no matter what, so it can be whatever you want/need

Does that mean that Insomnia will receive the authorization code from the authorization server, but it won't actually follow the redirect URI to deliver that code to the real OAuth2 client that listens at that URL?

Does Insomnia make any use of the "State" value that I provide?

I can't tell if my input may be wrong, or whether Insomnia can't handle my authorization server's response sequence.

How To Reproduce

1. Populate all the fields in the "OAuth 2.0" authentication dialog.
2. Press the "Fetch Tokens" button.
3. Authenticate with the authorization server in the child Web browser window.
4. Observe that Insomnia gets stuck, with the child Web browser window still showing, but blank.
5. Look for a way to diagnose what happened (e.g. inspect the URL of the final Web page shown, inspect the response body, or other details of the response, or find a log file), but not find anything.
6. Close the child Web browser window.
7. Press the "Fetch Tokens" button again.
8. Observe that the child Web browser window remains blank, and doesn't revisit the authentication Web form that I encountered the first time through. (Perhaps the authorization server already considers me to be authenticated, and is advancing immediately to responding with a redirection and an authorization code.)

Other Notes

It appears that there's at least one redirection step triggered by my organization's authorization server that Insomnia can't follow. The flow works well enough in the Web browsers I've used (Firefox and Safari).

[starJammer]

I had a similar issue to this before. I submitted this PR to fix my issue: #396

If you really want to Inspect things you CAN but you'll have to download the source and run Insomnia that way. It isn't hard honestly. It took me about 10 minutes to get going. Most of the time was spent waiting for npm dependencies to download.

Your redirect_url SHOULD be set to something that your oauth2 server will accept. The tooltip that says "Insomnia will intercept this no matter what" means that Insomnia will watch the url of the popup window. When your authentication server issues a redirect and if it contains a code=[code] query parameter it will read this code and close the window, regardless of where the redirect is actually going. It will then use this code to request a new access token at the token url.

When you run the project in dev mode you'll be able to run Chrome dev tools on the popup window and inspect network traffic and see what the issue is.

Best of luck.

[seh]

Yes, I do have the "REDIRECT URL" field populated with the URL registered for my OAuth client.

Using the latest Insomnia version (5.8.3.1068), the same problem persists—the child window sits there, with a blank page. For what it's worth, the page does have a title, no doubt specific to my company's authentication flow: "SAML 2.0 POST response."

[synotna]

I have exactly the same problem

edit: as far as I can tell from checking server logs, Insomnia never retries the request after it gets stuck the first time, even after restarting the client

[starJammer]

@seh, I would first suspect certificate issues. the certificate from the server should either be valid or you can open up chrome, navigate to the page and then accept the certificate as a valid one. otherwise insomnia won't load the page and it won't give you an option to accept it.

[seh]

I don't have Chrome installed. I use Firefox daily, and it has no problem with any certificates presented by the servers involved in this flow.

[gschier]

Hi @seh,

The way the auth window works is that it monitors for redirects and responds if the URL of a redirect matches the following Regular Expression.

new RegExp(`${escapeRegex(redirectUri)}.*(code=|error=)`);

Since your window is not dismissing, it seems that Insomnia is not able to detect a redirect that matches this. I'm not sure if that helps you at all but I'll make sure to add some debugging info to the next release.

[gschier]

... That regex essentially looks for a URL that starts with your redirect URL and contains either a code or error query parameter.

[seh]

Did you really mean "redirectUri?" Per RFC 6749 §4.1.1, the query parameter name is "redirect_uri." Here we can see the library I'm using to construct the URL using the latter value.

[gschier]

Ya, that's just the variable name I'm using. It uses redirect_uri under the hood.

The function you linked to in that library does not seem like the correct one. After the user logs in via the web form that Insomnia displays in a new browser window, your server should return a redirect response to the redirect_url with code and state query parameters appended. Insomnia will detect this redirect and pull code and state out of the URL if it can find them. If it cannot find them, it continues to wait forever for another redirect to happen.

If your redirect URL is https://mywebsite.com/oauth, Insomnia should be receiving a redirect after the user logs in with a URL that looks something like this: https://mywebsite.com?code=12345&state=something.

The step is outlined in the RFC here: https://tools.ietf.org/html/rfc6749#section-4.1.2

Can you verify that your server is generating and returning the correct HTTP redirect? If you could paste an example of a redirect generated by your server, that would help a lot.

[seh]

The referenced library function is for my client's construction of the request URL, presented to the user's Web browser. The authorization server does redirect the Web browser to the redirection URL I supply, together with the "code" and "state" query parameters that you mention. It all works fine in my Web browsers (Firefox and Safari); it just doesn't work with Insomnia.

[gschier]

Are you able to provide an example of a URL containing code and state that the server redirects to? If I can see an example, I might be able to identify the difference that is causing the problem.

I bet it's something small because I've testing Insomnia with many OAuth 2.0 APIs like GitHub, Dropbox, and others, and they all seem to work.

[seh]

Here's a sample URI that my client receives from the authorization server:

/oauth/callback/?state=T6KaJxTPqPMVNnGhQ6JSKYE2YtjxfnOXoAaEfm57sAQ%3D&code=l9gcAaibreBAkwa0cEIP_ZK42DXJHTBdHJUmPGt4PMGRJYdIILo8o_xvni0RveANDVy18vZcZ66mjifTF5ogIZVOe7ygQ9j2aAYo3U76UvKoeGgBpYq0ZAD8QZwbEPgFnJ6vmcbFkGrgWgTYvYjF6Ag6R48c6JWV6x_diCIkYYzBdQdeQqLfa7j9-ufPao6IbqFNO3TJOjMDJXdhxznJYYCRNtcLEWhbx9pe-CPueajHRLy-Nby9ULv4-mYefagYKC9FBJJShKNpDKD89DEHce2Zpo5F1GhS1O3UUp-w3Q_Vz1Mbj0BJCDSXu_rs7a-zgySm1Knikj7ExsP0jZNa7FGTJZopfFbFxjfdQ6rPopZ63axT0V09EvshuSrohDNS81lKNy7MYw7ITWwWxGgkUz54HuLgZeswYO6o5aGY2VNbEiemH_is9KAafgrhDI3kvepGP8MITTP-1xdo8kTaG3f9-s1U8BaykzpAR6rSZ2PJgGBgNY7PTYnQJZf3n8l7Ljl1pyNMnJA753YXYWOdjBbjieijSBHK7cjTwFW1jWgmQQK1TZIyIXtTAfcNGTvdf6kd8K0BNMm1Jbf0rYvU5QGX3DqpiixJewQtfWGermTuk7NK7DT-0Tpp3HXn2xc7Q9heAGq3FsMqW_Hj0IRWGuryU6JvUsQkdcrVEPrrtjzO_Ob5uS8j3411KTsSYDgoM1QKJSr_G5-0a6BwJycoI-mmlq_alJJ3jFDmvOGacZ1_GcCBg7xhyENaapBN5srTWDh-3rNeHXkJ1XPjoMXRzjNj6Iqz6ny_IWji57HYatquLQ5ykYADWt541CX367BV9JfxF8Nj1ySX2InrCo3fA_pqcz2mClzNkKcgMu-PtTcafs1j85OXb2vHXzSTF2_TmU_lsHUgDHRoHuljwDXXV6bB8BoKFqcIjOyrKGx129A1og%3D%3D

I'll also format it as a block quote so that it wraps:

/oauth/callback/?state=T6KaJxTPqPMVNnGhQ6JSKYE2YtjxfnOXoAaEfm57sAQ%3D&code=l9gcAaibreBAkwa0cEIP_ZK42DXJHTBdHJUmPGt4PMGRJYdIILo8o_xvni0RveANDVy18vZcZ66mjifTF5ogIZVOe7ygQ9j2aAYo3U76UvKoeGgBpYq0ZAD8QZwbEPgFnJ6vmcbFkGrgWgTYvYjF6Ag6R48c6JWV6x_diCIkYYzBdQdeQqLfa7j9-ufPao6IbqFNO3TJOjMDJXdhxznJYYCRNtcLEWhbx9pe-CPueajHRLy-Nby9ULv4-mYefagYKC9FBJJShKNpDKD89DEHce2Zpo5F1GhS1O3UUp-w3Q_Vz1Mbj0BJCDSXu_rs7a-zgySm1Knikj7ExsP0jZNa7FGTJZopfFbFxjfdQ6rPopZ63axT0V09EvshuSrohDNS81lKNy7MYw7ITWwWxGgkUz54HuLgZeswYO6o5aGY2VNbEiemH_is9KAafgrhDI3kvepGP8MITTP-1xdo8kTaG3f9-s1U8BaykzpAR6rSZ2PJgGBgNY7PTYnQJZf3n8l7Ljl1pyNMnJA753YXYWOdjBbjieijSBHK7cjTwFW1jWgmQQK1TZIyIXtTAfcNGTvdf6kd8K0BNMm1Jbf0rYvU5QGX3DqpiixJewQtfWGermTuk7NK7DT-0Tpp3HXn2xc7Q9heAGq3FsMqW_Hj0IRWGuryU6JvUsQkdcrVEPrrtjzO_Ob5uS8j3411KTsSYDgoM1QKJSr_G5-0a6BwJycoI-mmlq_alJJ3jFDmvOGacZ1_GcCBg7xhyENaapBN5srTWDh-3rNeHXkJ1XPjoMXRzjNj6Iqz6ny_IWji57HYatquLQ5ykYADWt541CX367BV9JfxF8Nj1ySX2InrCo3fA_pqcz2mClzNkKcgMu-PtTcafs1j85OXb2vHXzSTF2_TmU_lsHUgDHRoHuljwDXXV6bB8BoKFqcIjOyrKGx129A1og%3D%3D

The "state" value is one that I concoct; the "code" value is out of my hands, supplied by the authorization server.

[gschier]

Thanks @seh!

I see the problem. It's using a relative URL as a redirect, where Insomnia expects the URL to contain redirect_uri as a prefix. Something like https://mydomain.com/oauth/callback/?s....

There's nothing wrong with that, but Insomnia currently does not handle this case. I should be able to add a fix for this in the next release 👍

[seh]

Hey, that's great news. Thank you! Let me know when there's a candidate for me to test.

By the way, my redirect URL registered with the authorization server is an absolute URI, annoying as it is to have to commit the authority portion of the URI, but this is what my HTTP server reports as the URL that it receives.