insomnia: OAuth2 Authorization Code workflow breaks in v2022.7.5

Expected Behavior

After updating from 2022.7.4, I can longer fetch tokens using OAuth 2 for the grant type of Authorization Code. My settings have not changed as I’m using environment variables to populate the following

  • authorization_url
  • token_url
  • client_id
  • client_secret
  • redirect_url

Again with the same settings in 2022.7.4 I’m able to get all three tokens (refresh, identity, and access tokens). Only thing changed is the insomnia version.

Actual Behavior

Here is the response timeline

* Preparing request to https://<host>.auth.us-east-1.amazoncognito.com/oauth2/token
* Current time is 2023-01-25T15:45:38.254Z
* Enable automatic URL encoding
* Using default HTTP version
* Enable SSL validation
* Enable cookie sending with jar of 23 cookies
* Too old connection (231 seconds), disconnect it
* Connection 2 seems to be dead!
* Closing connection 2
* TLSv1.2 (OUT), TLS alert, close notify (256):
* Hostname in DNS cache was stale, zapped
*   Trying <ip address>6:443...
* Connected to <host>.auth.us-east-1.amazoncognito.com (<ip address>) port 443 (#3)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.auth.us-east-1.amazoncognito.com
*  start date: Feb 27 00:00:00 2022 GMT
*  expire date: Mar 28 23:59:59 2023 GMT
*  subjectAltName: host "<host>.auth.us-east-1.amazoncognito.com" matched cert's "*.auth.us-east-1.amazoncognito.com"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe6f0268200)

> POST /oauth2/token HTTP/2
> Host: <host>.auth.us-east-1.amazoncognito.com
> user-agent: insomnia/2022.7.5
> cookie: XSRF-TOKEN=edef6516-bf69-4ffc-b035-de67daeaae13
> content-type: application/x-www-form-urlencoded
> accept: application/x-www-form-urlencoded, application/json
> authorization: Basic <encoded clientid and client secret>
> content-length: 129

* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!

| grant_type=authorization_code&code=YlllszqiuopCZsdKW7KSkW0ZzR6kTv4u&redirect_uri=https%3A%2F%2Fredacted.net%2Fhome

* We are completely uploaded and fine

< HTTP/2 400 
< date: Wed, 25 Jan 2023 15:45:38 GMT
< content-type: application/json;charset=UTF-8
< x-amz-cognito-request-id: 08404251-957f-441e-b104-fcbbba395360
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< strict-transport-security: max-age=31536000 ; includeSubDomains
< x-frame-options: DENY
< server: Server


* Received 25 B chunk
* Connection #3 to host <host>.auth.us-east-1.amazoncognito.com left intact

| {"error":"invalid_grant"}

Reproduction Steps

  1. Click on Auth Tab
  2. Select OAuth 2.0
  3. Ensure Enabled is checked
  4. Grant Type :: Authorization Code
  5. Authorization URL :: is set
  6. Access Token URL :: is set
  7. Client ID :: is set
  8. Client Secret :: is set
  9. Redirect URL :: is set
  10. Click Fetch Tokens

Is there an existing issue for this?

Additional Information

I have cleared OAuth 2 sessions under the advance options and I have cleared all token input boxes before fetching new tokens. The unexpected result is the same.

Insomnia Version

2022.7.5

What operating system are you using?

macOS

Operating System Version

macOS Ventura 13.1

Installation method

downloaed from insomnia.rest

Last Known Working Insomnia version

2022.7.4

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 7
  • Comments: 24 (5 by maintainers)

Commits related to this issue

Most upvoted comments

Hey folks we’re merging @ltressens potential fix and it will go out in today’s beta release (2023.1.0-beta.2). Please reopen this issue if you are still having similar issues with the Authorization Code flow for OAuth2.

Ping @jackkav who wrote these 2 lines 2 months ago. I won’t be able to help that much on this.

I only have the issue that refreshing token does not work, Not sure if that is the same issue. It does not send the credentials anymore when I set it to “As basic auth header”. When I set it to “In request body” it works.

version: 2022.7.5

@oskargab if you turn off the auto update utility you can downloaded the 2022.6 release from GitHub and install it (that’s the only one I’ve tested so far). You could probably just downgrade to the last version before 2022.7.5 and see if that one works as well.

Ideally they would have a fix, but downgrading should work in the meantime

Please fix this before I jump off a bridge (:

Hello @helgeu !

Given the elements of your message, this error seems totally unrelated to the initial bug and its proposed resolution.

The error message “Error invalid_request Code challenge method is allowed, generally, but this client is not permitted to use it. undefined” is not part of Insomnia code base. This means that it’s an error returned by the OAuth 2 IdP server. It states that the client you are using is not configured for the flow you’re intending (to be checked upong your IdP documentation). Below the error message in your screenshot, there is the “Response timeline” button which may be very usefull to check which client id you’re passing to the server. It may be different than the one passed to your test with Postman. In any case it will help understand a lot the problem you’re facing.

Lionel

Hi @ltressens

You are partially right related to your gut feeling of this not being related to the initial bug. I found the real bug and its related to the setting up this initially.

In short the authentication.usePkce on line 79 and 80 in ./packages/insomnia/src/network/o-auth-2/get-token.ts are not initially set correctly according to the UI. In the UI its selected but in the code its undefined.

image

It seems that its first set when actually selected and not at the point where “USE PKCE” is turned on. This again does the request with PKCE but with plain and not SHA256.

So if you do the following:

  • start with a totally clean Insomnia
  • add a new request
  • add Auth code grant type
  • fill in all other relevant fields
  • select USE PKCE but do NOT touch the CODE CHALLENGE METHOD
  • make sure the client setup DISALLOWS plain in PKCE

Then the error will occur and it will “of course” be “Code challenge method is allowed, generally but this client is not permiteted to use it”, since the UI says SHA256, but the request for auth code flow is sent at ‘plain’.

There is a simple workaround of this of course: Just flick the plain/SHA256 and it works.