[Usability] Stale OAuth access token used after switching environments

[nathanwaldman]

Overview

• Insomnia Version: 5.1.0
• Operating System: MacOS 10.11.3
• Summary: Switching environments retains OAuth 2 refresh and access tokens when they may no longer be valid.

How To Reproduce

1. Create two separate environments "non-prod" and "prod".
2. In both environments define an oauthhost variable and give it two separate values representing two separate oauth hosts whose tokens are not exchangeable between the two oauth systems.
3. Create a route and configure it with OAuth 2 security, grant type "Resource Owner Password Credentials" and use the oauthhost variable when defining the Access Token Url.
4. Send the request and see that it fetches tokens and successfully calls the endpoint.
5. Change environments.
6. Send the request. Note that it does not update the access or refresh tokens and the result is a 401 Unauthorized.

[gschier]

This seems like a large frustration, thanks for pointing it out @nathanwaldman.

At the moment, tokens are stored per request, not per URL. Perhaps it would be better to key them on request+hostname which would provide the experience you are looking for.

[nathanwaldman]

The simple workaround is to clear the token on the request, so this isn't high priority. Your suggestion of tying the token to the request+hostname would solve my issue. In general, maybe it has to be tied to the request+username+hostname?

[gschier]

Ya, you are probably correct. The values used to generate the key might depend on what Grant Type is used.

[meagerman]

I also run into this issue constantly when switching environments.

While the proposed solution would work, I always thought it was a little weird to setup OAuth on a per-request basis. I had to copy my OAuth config across my entire set of APIs, even though they all shared the same authentication system, being part of the same API.

In other words, I was thinking that a better way to solve this would be to have the Authentication be linked to something more high-level than the request (like environment), so that when you switch to a different environment, the tokens would also switch.

[nathanwaldman]

Yeah, I often duplicate an existing request so that I don't have to reconfigure the OAuth security.

[audvin]

Clearing or refreshing Access Tokens on Environment switch would make a better UX than current.

[bvangraafeiland]

Would love to see folder-based authentication. Having imported a collection from Postman I now need to update the authentication settings for each request separately, which is quite tedious.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[t-ricci-enhancers]

We need this feature to share access tokens between request without reconfiguring all requests. We'd like to have a single request to autenticate, which will save the token in the environment, then use that environment variable as bearer on all other requests

[t-ricci-enhancers]

We would use those token even on separate endpoints

[gschier]

@t-ricci-molecle, I'm not sure this issue would help you do that (maybe provide more details on your use case if you think it does). It sounds like what you're after is reusable authentication.

You can already create an authentication request manually and use Chaining to reference a value from it's response in other requests.

[t-ricci-enhancers]

@gschier nope, not helpful with OAuth 2.0 (Auth0 in my case, which also requires custom GET query parameters which I cannot set in the Insomnia OAuth 2.0 autentication)

[gschier]

@t-ricci-molecle that make sense. I'm still not sure how what you describe relates to this issue, though. Can you elaborate?

Feel free to create a separate issue describing your use case.

[jaderobbins-wf]

Clearing or refreshing Access Tokens on Environment switch would make a better UX than current.

I would love to see this added. Currently we have several environments (that all share the same pattern): dev, sandbox, staging, demo, prod, prod europe, etc.

They are all different environments and have different id's/secrets. Clearing the token on environment switch (per audvin's comment above) would work great for what I'm doing.

[dRoskar]

I'm surprised this is closed. I think a big reason why people are switching to Insomnia from Postman is because of the more convenient token generating, only to find that it's still not totally convenient.

[gschier]

Reopening this!

[kossmoboleat]

The simple workaround is to clear the token on the request, so this isn't high priority. Your suggestion of tying the token to the request+hostname would solve my issue. In general, maybe it has to be tied to the request+username+hostname?

How would one implement this workaround? Would I use a plugin that evaluates some script before running a request?

We need the ability to clear tokens because we have users with different credentials and different stages. We often have to switch between them and cannot use Insomnia without the ability to clear the token cache (or having it cache the value including the username)...

[kossmoboleat]

@nathanwaldman @gschier

How would one implement this workaround? I still don't see how that would work, because I'm not aware how to access Insomnia token cache (and where I could trigger such a script)...

I would argue this has a higher priority if there's no workaround. For us it's a block before we could use Insomnia.

[nathanwaldman]

@kossmoboleat for my use case, for a particular request on the Auth/OAuth2.0 tab I just need to remember to click the "Clear" button after switching environments. Then when I send the request Insomnia will re-fetch the access token.

[kossmoboleat]

@nathanwaldman Ah right, that works. For some reason I didn't think of looking there. I had been experimenting with the env authentication plugin which of course has no UI...

[KurzedMetal]

At the moment, tokens are stored per request, not per URL. Perhaps it would be better to key them on request+hostname which would provide the experience you are looking for.

I'm kinda having a bad experience due to something similar to this.

Imagine this workflow happening in a few minutes

1. Having a Prod and Non-Prod environment setup with variables to handle OAuth that change between the envs
2. Open Non-Prod, Login window pops up (I also have to 2FA), finally I get my Token, and do stuff
3. Open Prod, get a new Token (Login + 2FA again), do stuff
4. Open Non-Prod again, I have to get yet another Token because the old one was replaced by the Prod Token (Login + 2FA again)

It would be nice if the Tokens were stored between different Envs and switching back and forth between Evns before their expiration doesn't force me to get a new Token (and having to Login and 2FA every single time I change Env which is quite annoying and time consuming).

EDIT: IDK if it is possible, but having the different Login+2FA cookies/sessions stored between the different Envs (to Refresh the tokens) would be awesome too. I usually have an awesome User experience if I don't switch Envs, but switching Envs is a pain.

[audvin]

It would greatly improve the UX to either automatically clear the auth tokens on env switching or support storing auth tokens by env.

[ricjohn]

One of the biggest pain points using Insomnia, hope this will be implemented soon 👍

[Tjax33]

This issue was created May 2017. It is March 2021 and this is still an issue.

Please fix this! I work in an enterprise environment and we are testing between postman and insomnia and I like the insomnia ease of use but this issue is a big deal.

It is such a simple fix. On environment change just clear all of the tokens automatically. Why hasn't this been implemented yet?

[pn-p]

In current Insomnia there's a setting in General -> Request / Response -> "Filter responses by environment", which makes responses not visible between environments, and this fixes the issue with tokens from one environment being sent on another.

[patrickhuy]

I tried this and did not have success, neither when retrieving tokens via request chaining nor when doing via configured oauth2 authentication