Kong
Requests don't pick up new OAuth 2.0 token
Expected Behavior
That if I generate a new token, all child requests will use new token.
Actual Behavior
When I change environment, I clear the token, generate a new one and it still uses the old token meant for a different environment.
Reproduction Steps
- Create a folder with
OAuth 2.0auth - create a child request with
Inherit from parentauth - generate a new OAuth 2.0 token in folder
- send child request
- change environment
- clear token
- generate new token
- send child request again
- seems like child request is using the token of old env instead of using the new generated token
Is there an existing issue for this?
- [X] I have searched the issue tracker for this problem.
Additional Information
it seems that if I duplicate the request and the duplication uses the new token
Insomnia Version
9.3.3
What operating system are you using?
Ubuntu
Operating System Version
Ubuntu Cinnamon noble 24.04 x86_64
Installation method
AppImage
Last Known Working Insomnia version
No response
@benyaa you can enable Filter responses by environment in Preferences
After enable this option, when you change the env, we will find the response matching your current environment
@benyaa you can enable Filter responses by environment in Preferences
After enable this option, when you change the env, we will find the response matching your current environment
not sure how it helps.. My requests are sent in the correct environment, that's why I get 401 - when I view the sent auth token what I see is the previous env auth token. When I try to manually use(meaning, change to Bearer token and copying the token to there) the newly generated token of the current env works. But it is not switched to it automatically using Inherit from parent.
@benyaa you can enable Filter responses by environment in Preferences
After enable this option, when you change the env, we will find the response matching your current environment
not sure how it helps.. My requests are sent in the correct environment, that's why I get 401 - when I see the sent auth token is the previous env auth token. When I try to manually use(meaning, change to Bearer token and copying the token to there) the newly generated token of the current env works. But it is not switched to it automatically using
Inherit from parent.
Does your environment includes OAuth info?
If not, does it mean that you manually change the oauth token in folder Auth and send child requests after switch env, it still use the old oauth token?
If so, could you please check the auth value displayed in folder Auth tab, whether its value is correct one or the old one.
@benyaa you can enable Filter responses by environment in Preferences
not sure how it helps.. My requests are sent in the correct environment, that's why I get 401 - when I see the sent auth token is the previous env auth token. When I try to manually use(meaning, change to Bearer token and copying the token to there) the newly generated token of the current env works. But it is not switched to it automatically using
Inherit from parent.Does your environment includes OAuth info? If not, does it mean that you manually change the
oauthtoken in folder Auth and send child requests after switch env, it still use the oldoauthtoken? If so, could you please check the auth value displayed in folder Auth tab, whether its value is correct one or the old one.
My env includes the OAuth 2 info that is used to generate the token.
So what happens is: I generate a new token -> if I create a new request it uses this new token, but if I run an already existing request - it uses the old token(generated by the previous env's oauth info.
Nothing in the auth tab.
@benyaa you can enable Filter responses by environment in Preferences
not sure how it helps.. My requests are sent in the correct environment, that's why I get 401 - when I see the sent auth token is the previous env auth token. When I try to manually use(meaning, change to Bearer token and copying the token to there) the newly generated token of the current env works. But it is not switched to it automatically using
Inherit from parent.Does your environment includes OAuth info? If not, does it mean that you manually change the
oauthtoken in folder Auth and send child requests after switch env, it still use the oldoauthtoken? If so, could you please check the auth value displayed in folder Auth tab, whether its value is correct one or the old one.My env includes the OAuth 2 info that is used to generate the token. So what happens is: I generate a new token -> if I create a new request it uses this new token, but if I run an already existing request - it uses the old token(generated by the previous env's oauth info.
Nothing in the auth tab.
Since you're using Inherit from parent, can I see the auth tab of folder which contains your request.
@benyaa you can enable Filter responses by environment in Preferences
not sure how it helps.. My requests are sent in the correct environment, that's why I get 401 - when I see the sent auth token is the previous env auth token. When I try to manually use(meaning, change to Bearer token and copying the token to there) the newly generated token of the current env works. But it is not switched to it automatically using
Inherit from parent.Does your environment includes OAuth info? If not, does it mean that you manually change the
oauthtoken in folder Auth and send child requests after switch env, it still use the oldoauthtoken? If so, could you please check the auth value displayed in folder Auth tab, whether its value is correct one or the old one.My env includes the OAuth 2 info that is used to generate the token. So what happens is: I generate a new token -> if I create a new request it uses this new token, but if I run an already existing request - it uses the old token(generated by the previous env's oauth info.
Nothing in the auth tab.
Since you're using
Inherit from parent, can I see the auth tab of folder which contains your request.
I have the same problem and it doesn't require an env change. It is enough to change the user and get a new token in the parent folder. This is not picked up by child requests where a request was made (one requirement maybe that the old token from the old user is still valid).
Repro:
-
Get token for user1 in parent folder via OAuth 2.0.
-
Send request in child with "Inherit from parent"
-
This steps seems to copy the token into the child request itself
-
Go to the parent folder, clear Oauth2 session and clear tokens, change user1 to user2, login and fetch new tokens
-
Go to child request, send again => it still uses token of user1.
-
If I switch to Oauth 2.0 in child request, I see that there is the old user1 token still stored (although the Oauth2 settings are missing, I guess these aren't copied to the child request)
-
If I now manually clear the tokens in child request, switch back to "Inherit from parent", and send the request again, the user2 token will be picked up again.
I see the same behaviour when just deleting the token in parent folder: this will not clear the token from child request (even though "Inherit from parent" is selected) and child requests continue to use the token that should have been cleared.
Just switched to Insomnia 10.0.0 via Snap to test it.
Also tested it with multiple requests, problem seems to always be that tokens are copied to child request, but then never deleted or updated. Start in a clear state (so no stored tokens for all requests), then login user1, send request1, login user2, send request2, login user3, send request3 => now all three requests use different tokens despite all of them having "Inherit from parent" selected and parent having user3 token configured.
We wanted to switch over to Insomnia from Postman, but this is a breaking bug for us. It is also a very very dangerous bug, never knowing which credentials you are using when sending requests renders Insomnia completely useless for us. Not sure if I am missing some setting or doing something dumb, but being confident I know what the software does when I click "Send request" is literally the number 1 priority for me.
+1 Still an issue. My nasty work around is to duplicate the request and delete the old one. However the bug itself has led me on a wild goose chase a few times before I realised it wasn't getting the latest token.
+1 still an issue. I could work around by switching from "inherit from parent" to "OAuth2", then clear the tokens and switch back to "inherit from parent"
We have exactly the same problem.
Oauth is configured on a parent level. When I authenticate to environment A and then I switch to environment B and reauthenticate then
- token on a parent level really comes from env B (checked with https://jwt.io/ )
- but the token really sent in the child request still comes from env A
Behaviour is consistent, not random one.
I confirm that "workarounds" from @vivaladan and @JanReimer works
+1 still an issue for me in 10.2.0. My use case and repro steps are exactly as the original posted submitted.
- Set oauth2 at a folder level.
- Create oauth settings (token url, client id, secret, scope, etc.) based on environment variables (UAT and prod for example).
- Create child requests that "inherit from parent".
- Fetch token and issue request for UAT environment.
- Switch environment to prod.
- Issue same request for new environment and see the old UAT token is used. You can see the previous environment's token value being used in the console for the request.
I usually just duplicate the collections folder and delete the old one. Slightly annoying, but it works for me.
+1 still an issue. I have latest Insomnia 10.3.0 (Windows, 20.12.2024)
Exactly same problem as described by topicstarter and others
UPD Looks like the problem is here: https://github.com/Kong/insomnia/blob/37ef377e8b2b04033a1659ee9b638dfc715aebd1/packages/insomnia/src/network/o-auth-2/get-token.ts#L23
Session stored in chromium local storage
I also have this issue, and apparently it has been a problem since 2017... https://github.com/Kong/insomnia/issues/260
The workaround posted by @Grillpfanne should be made more prominent at the top. Basically: Switch the request auth to OAuth2 and clear the token, then switch back to inherit from parent.
Really the token should never be stored onto the request so it's always picked up from the parent.
I also experienced this problem. Probably switching the http client. looks like this bug does not get the needed attention.
Version 11.0.2 on Win10 I have nested folders like this Project (folder) Auth - Bearer --Module (folder) Auth - ApiKey ----Action (request) Auth - inherit from parent
Request doesnt pick up its parent's (Module) Auth settings, but instead will take root Auth settings (Project).
Still not working for me (on a local scratch pad if that makes any difference). Similar nested folder situation to SOLINARY above.
I am on MacOS not Windows, though.
@snckirkmarken if I understand correctly, in nested folder structures, the highest level parent's auth is being inherited, but you expect an intermediary folder's auth to be inherited (closest to the actual request), is that right? That's how I'd expect it to behave.
If that's the case, and it's not working that way, I'll move this to a new issue. The narrowly scoped bug with OAuth2 tokens is fixed, but this seems to be more widespread (i.e. not limited to OAuth2).
@snckirkmarken if I understand correctly, in nested folder structures, the highest level parent's auth is being inherited, but you expect an intermediary folder's auth to be inherited (closest to the actual request), is that right? That's how I'd expect it to behave.
If that's the case, and it's not working that way, I'll move this to a new issue. The narrowly scoped bug with OAuth2 tokens is fixed, but this seems to be more widespread (i.e. not limited to OAuth2).
Hi @ryan-willis That is the case for me as well. I have the structure:
Main Folder
- SubFolder -- Request 1 -- Request 2
In SubFolder I have Auth type Basic, in Main Folder Auth type Bearer Token. With this setup, the Request 1 (Auth type "inherit from parent") does not succeed. When I change to:
SubFolder
- Request 1
- Request 2
it works.
The first setup is what I expected to work. (I was migrating from postman where this worked.) I can live with the workaround described, but added this info for you anyway.
Version: Insomnia 11.2.0 Build date: 5.6.2025 OS: Windows_NT x64 10.0.19045 Electron: 35.1.5 Node: 22.14.0 Node ABI: 133 V8: 13.4.114.21-electron.0 Architecture: x64
