OAuth2 Authorization Code workflow breaks in v2022.7.5

[kourtneya]

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?

• I have searched the issue tracker for this problem.

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

[jofleck]

I can confirm this. Suddenly a working configuration stopped working.

2022.7.5
macOS Ventura 13.2 (Apple Silicon)

[Rens660]

I have exactly the same issue here ✋

2022.7.5
macOS Ventura 13.1 (Apple Silicon)

[jordibeen]

Same here! Also running Insomnia v2022.7.5 on macOS Ventura 13.1.

[helgeu]

For some reason insomnia captures code, that is being sent to auth instead of the one that would be sent to redirect url. Therefore the presented code to token endpoint is incorrect. Short story. Thx to collegue who discovered it...

2022.7.5
Windows 10

[patmagee]

I can confirm as well. v2022.7.5 on monterey 12.3

[mball]

Confirmed Authorization Code flow broken. v2022.7.5 on Windows 10
{"error":"invalid_grant","error_description":"AADSTS9002313: Invalid request. Request is malformed or invalid.

[mrommel]

I can confirm this as well for v2022.7.5. Please fix.

[pthum]

Same here with v2022.7.5 against a keycloak instance, responding with
{"error":"invalid_grant","error_description":"Code not valid"}

[oskargab]

Please fix this before I jump off a bridge (:

[Wotee]

Same issue.

2022.7.5
Win 10

[patmagee]

@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

[denysandriyanov]

Anoying

[jdekock]

Same issue over here. Downgrading worked, but not ideal.

Any update on a fix?

[blieb]

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

[mjanssen]

Bump for this issue. Version 2022.7.5; Apple silicon; OSX Ventura. Downgrading to an older version seems to work for now.

[ltressens]

Same here.
We use Keycloak with 2FA activated.
After login+password entered, Keycloak redirects to a URL that has the shape :

https://server/realms/production/login-actions/authenticate?session_code=LGhtwjhmG7MlP-suup2QYLRgddNpJiM0vAfeMv5lwR4&execution=296f79af-cb74-43e1-8cc2-bd1a4be14846&client_id=api-gateway&tab_id=_A7qvN8c1bI

Insomnia tries to read the code in this URL because it encounters the pattern code= in the string at session_code=.
The OAuth flow cannot be completed because this is not the OAuth 2 code, but an intermediate step.

Making the Redirect URI optional should have used a on/off flag in the main settings or in the OAuth settings tab to allow such flows to work as before. All our Insomnia collections are now unusable for us since this update.

[filfreire]

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.

[ltressens]

Just installed the beta .dmg on Mac.
My OAuth2 workflow with 2FA on Keycloak is back on tracks ;)

[helgeu]

This seems unfortunately NOT to be fixed in the latest beta. With same setup in postman it works nicely.

The error is now: OAuth 2.0 Error invalid_request Code challenge method is allowed, generally, but this client is not permitted to use it. undefined

Version: Insomnia 2023.1.0-beta.3
Build date: 16.2.2023
OS: Windows_NT x64 10.0.19044
Electron: 22.0.0
Node: 16.17.1
V8: 10.8.168.20-electron.0
Architecture: x64

@filfreire @ltressens please do reopen

[ltressens]

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

[helgeu]

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

Thanx for your answer @ltressens!

There is in fact no Response timeline here. Which kind of put me off, and I should have extended the initial image to showing that. Added it here now.

So I am not so sure about the Idp being the problem here either since Postman handles the exact same setup.

I tried during the weekend to get this project up and running but did not manage to get it to debug in Visual Studio Code. So if there exists some explanation of getting this up and running on Windows (preferably) with Visual studio Code I can debug the exact case and find out a bit more about whats causing it.

I did use Fiddler for capturing the networking traffic and that seemed quite ok to me, and no errors from the Idp as far as I could see.

[helgeu]

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.

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.

[ltressens]

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

[Yc-Chen]

Same issue here, waiting for the new version release...