OAuth 2 token refresh fails

[vivaladan]

Expected Behavior

Refreshing tokens whether manually or automatically should work. It previously worked, but one of the more recent updates seems to have broken it.

Actual Behavior

Clicking refresh shows [oauth2] Failed to refresh token url=https://[omitted]/connect/token status=400

A work around is to clear and fetch tokens again, where it gets issued a new id/access/refresh token. I have taken the refresh token and tested manually that it works.

It seems that something insomnia is passing with the connect/token request, perhaps in the body, is not correct and the identity server is rejecting it with a 400.

I'm unable to dig into any details about the request. There is no 'response timeline' button like a successful OAuth 2 request would give.

Another work around is to roll back to 2022.7.0 which can refresh correctly

Reproduction Steps

1. Navigate to a previously working request
2. Open OAuth 2 authentication section
3. Click 'Refresh Token'

Is there an existing issue for this?

• [X] I have searched the issue tracker for this problem.

Additional Information

Both 2023.1.0-beta.3 and 2022.7.5 have this problem.

Insomnia Version

2022.7.5

What operating system are you using?

macOS

Operating System Version

Ventura 13.2.1

Installation method

downloaded from insomnia.rest. also auto update.

Last Known Working Insomnia version

2022.7.0

[filfreire]

Should be fixed in https://github.com/Kong/insomnia/pull/5763

@vivaladan can you still reproduce this in 2023.1.0-beta.3 ?

[vivaladan]

I think it's unrelated to #5763, I can reproduce.

I was checking logs and found that the difference in the refresh token request was that it was missing client_id and client_secret from the body. Which led me to look at the select list option called 'Credentials' which has the options 'In Request Body' and 'As Basic Auth Header (Default)'.

On previous versions '2022.7.0' and prior, this setting didn't affect refreshing. Which is correct as per the spec 'The Client sends the parameters via HTTP POST to the Token Endpoint using Form Serialization'.

I found that setting it explicitly to 'In Request Body' fixes the issue for me in newer versions. But I would suggest caution because from what I can tell (according to the spec) it should always be passed within the body at least for refresh requests. I'm attempting to confirm whether this is correct behaviour.

[Samuel-B-D]

@vivaladan To add to this, setting the Credentials fields to 'As Basic Auth Header (Default)' works properly for the initial /token call with grant_type=authorization_code; the Auth Header correctly include the client_id and client_secret. However, in the refresh token flow, the header is simply not being sent anymore (it was sent before).

[defrimhasani]

This is still happening on 2023.2.2.

[vivaladan]

Concur. I rolled back to 2022.7.0 and will stay there until this doesn't break all my collections.

@filfreire Currently not fixed. The setting should not effect token refreshes.

[dweber019]

Still having the issue with

Version: Insomnia 2023.4.0 Build date: 4.7.2023 OS: Windows_NT x64 10.0.19044 Electron: 23.3.9 Node: 18.12.1 V8: 11.0.226.20-electron.0 Architecture: x64

As workaround use

[thomas-limin]

Hello I reproduce this issue with

Version: Insomnia 2023.5.8
Build date: 07/09/2023
OS: Windows_NT x64 10.0.19045
Electron: 25.2.0
Node: 18.15.0
Node ABI: 116
V8: 11.4.183.23-electron.0
Architecture: x64

I confirm the workaround : in oauth2 advanced options , set credentials : "in request body"

according to oauth2 spec, the Client, here insomnia, MUST authenticate to the Token Endpoint using the authentication method registered for its client_id. authentication method includes HTTP Basic authentication, including the Client Credentials in the request body etc…

I have analyzed the timeline file with details of the refresh token request: I confirm that the needed Authentication http header is missing. as a consequence, insomnia obtain a http 400 error with this content: {"error":"unauthorized_client","error_description":"INVALID_CREDENTIALS: Invalid client credentials"}

[emman122]

This is still happening on 2024.2.2.