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
- Click on Auth Tab
- Select OAuth 2.0
- Ensure Enabled is checked
- Grant Type :: Authorization Code
- Authorization URL :: is set
- Access Token URL :: is set
- Client ID :: is set
- Client Secret :: is set
- Redirect URL :: is set
- 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
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 7
- Comments: 24 (5 by maintainers)
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 (:
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 itsundefined
.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:
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.