[Feature Request] 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]

👋 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.

[gschier]

@afeblot I definitely don't think we should get rid of the per-request authentication but I think the idea of a global authentication setting is a very interesting idea 💯

My idea was to similarly define authentication at the workspace level, and have those available in the request Auth dropdown. This could be extended with your suggestion by providing an additional checkbox or selection to override auth on all requests with the global one.

[afeblot]

That would be awesome 😄 I can't wait to see it done!

[adematte]

@gschier this would be an awesome feature but sounds like it will require a lot of work.

It may be a stupid idea but how about just empowering existing environment variables with reserved keys ? Environment variables are great because they already allow to override configuration between requests and often already hold auth information. The reserved keys would allow setting specific items in the UI, such as the auth type and corresponding configuration.

For example, to define an oauth2 implicit config:
{ "INSOMNIA_auth_type": "oauth2", "INSOMNIA_auth_oauth2_grant": "implicit", "INSOMNIA_auth_oauth2_callback_url": "http;//localhost", "INSOMNIA_auth_oauth2_secret": "XXXXXXXXXXXXX" ... }

[katanacrimson]

@adematte That's great for configuration, except that's something that can be implemented with what's currently there. The purpose of this functionality is not sharing parameters for authentication (such as OAuth2 params), but the result of authentication (such as API tokens, access tokens, etc.)

[C45tr0]

Being able to setup global authentication methods and switch between them would be awesome. My use case supports both api keys and oauth2 tokens currently and this would help a lot.

I would love to help on this. Is there a good starting point? And maybe we could break this up into multiple pieces. Sounds like a big chunk to take right out.

[hjkelly]

I'm a total Insomnia fanboy, but every now and then I wish it had some feature similar to Postman's ability to update the environment based on the request. I understand that's less-than-elegant in some ways.

But one reason I hope it's a universally-shareable resource like that is because I frequently need to switch between grant_type=client_credentials and resource owner password/credentials, but I want every request to use my current token (regardless of how I last got/set it). Otherwise I'd have to create separate requests for each auth tab mode, or manually copy/paste into an environment variable.

I'm having trouble understanding where this proposal stands, but I hope it can somehow help me. Maybe what I'm looking for is closer to what's described in #1051 or #1167?

Also, I primarily work on backend web apps, but if there's any way I could help with this solution, let me know!

[davidfergo]

I think it should be like in Postman: Let define an Authorization at folder level and each request inside decide if inherit it (as a authenticaton type). In Postman, when you are editing a Collection, you can set Authorization. After that, each request can be choose between inherit (default) or define its own authorization method.

[afeblot]

@eudavidf : That's not enough. You might need different auth types per environment for example. There are other solutions already suggested in this thread which address all use cases better. Like mine 😄 😜

[davidfergo]

@eudavidf : That's not enough. You might need different auth types per environment for example. There are other solutions already suggested in this thread which address all use cases better. Like mine 😄 😜

You're right, your proposal it's more powerful :-)

[stale]

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.

[katanacrimson]

...Any way to make stale bot not touch this issue other than having to repeatedly bump it? Stalebot is great if it's a support request, but this isn't such.

[gschier]

It won't touch it. I renamed some tags which is why it happened again

_{Sent with GitHawk}

[crtl]

Any news or updates when this will be finally released?

[hnryjms]

Couldn't we achieve all ^ above if we modify the Request function in Insomnia to optionally take in an alternative Request item (as opposed to "Current" only)?

By selecting the OAuth2 token from another request, Insomnia would launch the authorization flow of that shared Request when you run the sub-Request ....

Then you could add an Environment on your Group such as:

{
  "accessToken": "{request 'oauth2', /* ... */}"
}

And then refer to the {{accessToken}} variable in all requests below that folder, which points out to the one OAuth2 authorization definition from your shared request.

[NHSNeil]

Would be such a boon! Tired of copy / paste 📦

[tostringtheory]

@hnryjms / others-

I was just hitting upon this myself for my current work project. I ended up utilizying @hnryjms 's solution regarding access other requests' tokens. It would be nice if the default request template tag were able to specify the request, but it can't. I just published a new plugin insomnia-plugin-accesstoken that adds a token templating tag, AND allows you to reference the token of any request in the workspace:

The plugin will also alert you if the token is empty, or expired. The generated string utilizes the provided "Prefix" set for the specified requests authentication properties.

Hope this helps everyone, I was starting to look at other REST clients before I realized this was a simple solution. To be frank, this is my first public NPM package, so please feel free to provide any feedback if you see any points for improvement.

-tostringtheory

[petrdvorak]

@tostringtheory Thank you for the great plugin! Could you please possibly improve it so that it does not prefix the token with undefined in case there is no prefix in OAuth2 tab, and only returns the raw token value in such case (without any prefix)? There are use-cases (such as the /oauth/check_token endpoint) where having the raw token is a must... (Edit: Noticed I can use space in prefix as a workaround.)

[oskaremil]

I think, why make shared authentication mechanisms that advanced and possibly dependent on each ones workflow ?

I am just throwing in my two cents here; How about an extra field at the top of the Auth tab labeled 'Authorization Profile'. The initial value is empty

Before or after filling out the authorization fields you can set a name in the Authorization Profile and then the information entered in the fields is persited on a per workspace setting.

Next time you create a new request you just select the Authorization Profile from a dropdown

[finnmerlett]

@tostringtheory Thank you for the great plugin! Could you please possibly improve it so that it does not prefix the token with undefined in case there is no prefix in OAuth2 tab, and only returns the raw token value in such case (without any prefix)? There are use-cases (such as the /oauth/check_token endpoint) where having the raw token is a must... (Edit: Noticed I can use space in prefix as a workaround.)

I've made a pull request fixing this

[kokoshneta]

@gschier :

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.

I’m trying to do this, but the documentation on how to use the plugin is… sparse, and I haven’t been able to locate anywhere else where it might be described in more detail.

I’ve installed the plugin, and it appears in my settings as installed.

I’ve added a Base Environment variable DEFAULT_HEADERS and set the two headers I need (X-AppSecretToken and X-AgreementGrantToken) to their respective values.

What now? How do I now apply these to new requests I create in that environment? When I create a new request, the values of the two properties in the DEFAULT_HEADERS variable are available to use when typing, but the request has no headers. Is the purpose of the plugin not that request headers should be automatically populated?

What am I missing?

[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.