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

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).

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 6
  • Comments: 29 (17 by maintainers)

Commits related to this issue

Most upvoted comments

I made a new issue for some of the improvements that are being discussed here. I’m going to close this one as the original question has been answered.

I totally agree with you that it shouldn’t matter. However, there are users like @starJammer who need the more strict URL matching because they multiple URL in their flow that contain a code= parameter.

I think there is a way to make both sides happy.