Define authentication setting on environment of global level

[rroukens]

• Insomnia Version: 6.0.2
• Operating System: macOS High Sierra (10.13.6)

Details

I connect to one API service with many requests. I now have to set the authentication settings on each request. But, because it's the same API, the settings are always the same. Even the token could be reused between the requests. Of course the process can be made a little easier with parameters, but still, for each request I have to go to the Auth section, click the appropriate settings, fill in the credentials, etc. Can this not be defined per environment of globally and reused on all requests? (Just like an interceptor?) That way, I can define it once, or per environment and all requests in that project or environment use these authorization settings.

I hope this is not already asked somewhere. I searched the issues, but couldn't find it anywhere.

Rogier

[welcome[bot]]

👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

[MateuszDabrowski]

I can only agree with that feature request - I have dozens of API calls for one API and when I'm periodically asked to change the password for that API I currently must update manually each call with the new hash.
Optionable tokenization would make it a breeze.

[gschier]

I think there are a few issues related to this floating around but they are fairly outdated at this point.

A while ago, I tried to implement something called Parent Requests (#598) which would provide a way for requests to inherit attributes from another one. However, I ended up deciding against it for now.

Reusable authentication is perhaps one of the most requested features, however, so it might be good to solve it as a specific issue on it's own.

I'd like to open up this issue for discussion. Do either of you have ideas for now re-usable authentication might work from a user-experience perspective? My initial idea would be to have a new dialog to create authentication entries. These entries would be selectable from the auth dropdown on each request.

A few other notes

@rroukens – if your token can simply be entered in a header, you could make use of the Default Headers plugin to set it on every request.

@MateuszDabrowski – to address your specific issue of having to modify each request to update your password, you can make use of Environment Variables instead, allowing you to store your password in a single place and update it easily.

[rroukens]

Hi Gregory,

First of all, thanks a lot for looking into this. Of course, storing a token in a variable is a work around that works, but still needs manual action every (in our case) 24 hours. While the whole functionality of authentication flows (oauth2 in our case), that fetches a new token, pass token as header, etc. is available in Insomnia on request level.

The only thing I can come up with is that you can define the authentication flow on a higher level, which would be environment and then base environment. The authentication settings will then be inherited from base environment -> environment -> request.

From a UI perspective I would imagine that the current 'Manage Environments' screen (cmd+E) would have tabs like the requests have. First tab would be 'properties' of whatever, where you can define properties in JSON format as is already possible now. The second tab will become the same tab as the Auth-tab on request level, where you can define your authentication settings for all requests that use this environment.

Maybe in the future other tabs can be added to support more functionality on environment- or base environment-level.

I realize this is a big change probably but I can't think of a better way.

Regards,
Rogier

[afeblot]

Hi,
I'll be glad to see this happen too :-)
Another way is to copy what postman does: Allow setting the auth at the folder level, which will apply to all requests in this folder.
I'm not sure adding the auth to the env level works fine with this use case: multiple envs to be used with the same set of requests, using the same auth (in which only some env property values differ). I feel like I'd only want to define the auth once for this request set, instead of duplicating it in each env.

[alexandrul]

Have you tried to chain the requests? https://support.insomnia.rest/article/43-chaining-requests

For my application I'm sending a single request to fetch a valid token and then I'm using it for all the other requests (until a new token is needed, usually due to a restart of the target application).

[afeblot]

@alexandrul, this does not work when you use the Oauth2 Insomnia capabilities: The token is part of the request parameters, not from its response. So it's available from the template tag "Request - reference value from current request", which, sadly does not allow taking reference values from other requests, while the "Response - reference values from other request's responses" does not provide access to the token.

[gschier]

@afeblot yes, I agree that the environment is probably not the best place to put authentication. My suggestion would be to store the reusable authentication at the workspace level. Then, environment variables could still be used within it.

However, I have seen users who have different authentication types per environment. For example, OAuth for production and a simpler Basic Auth for development. I think this is probably a rare case though and not worth supporting.

[gschier]

@alexandrul and @alexandrul There is a tag to access the OAuth 2.0 token of a specific request.

[afeblot]

@gschier
of a specific request?
The only template tag I saw to access the token is "Request - reference value from current request". Which does not solve the issue.

[afeblot]

@gschier I think your initial proposal to define authentications on their own, and to refer to them in each request is a good solution: simple enough, and answering all possible use cases.

[gschier]

Oh whoops, you're right. That only works for the current request.

[meagerman]

@gschier's idea to make authentication it's own thing, separate from environment, that can be linked as a drop-down from the auth menu of each request would solve my use-case.

My use-case is I have multiple environments, each representing a different instance of an API (test, staging, production, demo, etc). I often switch between them. I used to use the environment variables to store my tokens, and this was OK -- I would replace the token once a day and all requests would start sending it in a header. Then Oauth 2 support was released and I switched over to that, which is smoother for refreshing tokens. But the problem is when I switch environments, the auth state is remembered from the other environment, meaning they all share tokens.

Another way to make it "just work" would be to keep an authentication state not per request, but per environment, or even per environment-request, so that when I switch environments, the OAuth state would also get switched.

[bobvanderlinden]

I think it would be nice if we could define authorization/session separately within the scope of an environment and be able to refer to that authorization from endpoints and 'endpoint directories'.

Currently we can choose an authorization-type per endpoint, but that does not make sense in most cases, as you want to share a session of a certain authorization-type between endpoints and not the authorization-type itself.

This would also make it possible to refer to different sessions (= different users?) for different endpoint-entries.

[afeblot]

I think I might have a very simple yet very flexible proposal here:

The same way we define a global pool of environments in which we select the one to currently use (whatever request/folder we're in), we could have a global pool of authentications (which would as well use environment variables if needed, because why not, that's useful), and we can just select which authentication we currently need to use with whatever we do. One obvious mandatory additional choice in this authentication selector is "None".

So the standard Insomnia workflow would be:

• define your environments
• define your authentications (based on environments values if needed)
• define requests
• Select active environment
• Select active authentication
• Execute requests

This is enough IMHO to allow every possible usecase.

On top of this, we might still want to make things more complicated by adding specific authentication at request/env/folder/workspace level, but I would just get rid of all of this and only keep the global authentication selector.

[rocketraman]

@kokoshneta It works when you define the default headers at the folder level. Not sure if that is the intended behavior or not though. However, I just noted a bug that per-request settings do not override these defaults, which makes this "solution' less than optimal.

[vraamark]

I guess that Insomnia still doesn't implement auth on a global level? I've tried to find info on it. I can see the feature request going back almost 4 years.

If Insomnia could implement auth the same way as Kreya for gRPC (looks like they got a lot of inspiration from Insomnia UI-wise), all would be solved I think.

In Kreya you can define default Authentication Settings by name. That auth name can be selected on a folder level or request level.

Using OpenID + Authorization Code will open a login form on your first request or if your token expires. No need to copy/paste tokens around and no need to manually renew a token. It just works.

I'm not saying that the option to define auth for each request should be removed, but for most people that is the least useful feature in the world. I cannot imagine any situation where I have 50 requests with 50 different auth definitions.

Have a look at the docs here: https://kreya.app/docs/authentication

[wdawson]

Thanks for the link and suggestion @vraamark ! We definitely want to make things like this more straightforward. We'll try to figure out when we can get around to this. It's definitely one of the top requested features.

[neubarth]

Our workaround for this issue is to use the "Duplicate" feature extensively:
Whenever we create a new request, we duplicate an already existing request which has the same OAuth2 details.

Now we only need to log in once, when executing the first request. All other requests can be executed without further authorization.
I assume that the requests share the same OAuth2 session, but did not find any documentation for this really useful feature.

[matthieugeerebaert]

Was evaluating insomnia after many years with postman, we have more than 100 Apis in our company ( different teams etc )
Many workflow starts with an OAS import, so no duplication request workaround.

And here facing the reuse of OpenId connect token :(

Not usable at all :(

At least a way to populate a variable with the resulting access_token when using oauth2 on any request, or even more straight forward an access_token variable ( or function ) with a dedicated wizard to retrieve an access_token ( same form as per request ) as suggested above ( maybe a specific "OAuth" request added to the collection, without any url, send button etc, just the form to retrieve token )

[ThaDaVos]

Is there still no better way than just duplicating requests?

[Idane]

Is there anything on this? This is hindering our adoption of Insomnia due to having a large OIDC API

[muuvmuuv]

Is there are reason this is a discussion not an actual issue and "planned"/"feature request"? Really a blocker for a lot of people coming from other tools like Postman.

[dlebee]

I would propose I guess a more simpler solution, that isn't inherited requests or parent requests.

In the Auth section of a request, we could select configured authentication

In that screen we could select an authentication that we created in a new screen that allows you to manage reusable authentications.

The same screen/design/parameters used to configure the authentication for a request can be used to configure reusable authentications.

That makes it a more simple authentication than implementing inherited requests and I prefer it to be honest, I like to organize my features by modules not by if I need to be authenticated or not.

[Isengo1989]

I like the tool, but this is currently a dealbreaker for me. Sadly nothing has changed after 5 years 😞

[sparrowt]

Likewise, a reply on https://news.ycombinator.com/item?id=36790220 suggests there is a fix in the works but no official word here?

[alishah730]

so no feature even after 5 years? 😞

[james10424]

This is an absolute dealbreaker. I have dozens of APIs and I have to manually set the sam API keys to each? Will be looking for alternatives.

[dougbreaux]

I wonder if new fork https://github.com/ArchGPT/insomnium might be able to pursue ...

[KhogaEslam]

I finally found this working plugin
insomnia-plugin-global-headers

[subnetmarco]

Heads up that after pre-request scripting we will be looking at both global authentication and global environment variables that can be re-used across multiple collections. I agree this capability is much needed and can't ship soon enough.

[subnetmarco]

Update: we started working on supporting global environment variables, which will ship within a month. It will also be support in pre-request scripting.

[mcorkum]

Exciting! Literally the only thing stopping my organization from switching over.

[KhogaEslam]

Great!
Can we get multi-tabs also, please?

[subnetmarco]

Yes! In the next 3-4 weeks the focus is post-request scripting, globals, folder level authentication and performance improvements (including improvements to the offline experience). After this scope of work is completed, we can start with multi-tabs and others.

We have now reached good velocity and we are closing the most requested features one after another, multi-tabs is high up there.

[subnetmarco]

Global environments will be shipping in the next Insomnia 9.3 GA:

• You will be able to create as many global environment files as needed in each project, and they adhere to the storage of the project, so they can be 100% local, or shared via Cloud Sync or Git Sync based on your requirements.
• You will be able to select global environments in collections, mocks and design specs, and you will be able to programmatically get access to them in our scripting (pre-request and after-response scripts, the former available since v9.0 and the latter also shipping in the upcoming 9.3 GA).
• You will be able to create private sub-environments within a global environment that are always local, private and not exportable independently by the storage settings of the project.

I estimate this to be available within 4 weeks, maybe sooner.