This isn’t a technical how-to question, rather looking for some best practice advice:
Where should we be storing our access_tokens (typically those that last from 5mins > 60mins, which we would generate/request either on a timed basis or every time we make a request), as a Collection / Environment / Global variable?
To make things more confusing, this is a Shared Workspace with multiple people collaborating: assuming we name our access_tokens for various systems correctly it probably doesn’t matter and we can share tokens, but just curious if anyone has run into conflicts doing this?
Confidential information should be in current values within an environment.
Not in collection or global variables, and not the initial values.
The current values for environments do not get synched to the Postman cloud and are not included if you export the environment as a JSON file to be added to your code repository. These secrets should not be in your code repository either.
These secret artefacts should be stored in a key vault or another secure repository for sharing between team members and jobs\scripts.
When developing and creating your collections locally (in the web or desktop app), its basically a manual cut and paste job from the key vault.
When you automate this within your continuous integration tool, one of the first items in the job pipeline would be to retrieve the secret variables from the key vault to be used in the pipeline.
We use Azure Pipelines and Azure Key Vault in conjunction with Newman for this which is pretty seamless.
Microsoft best practice for key vaults is to have individual ones for each application, and for each environment. Separation between the key vaults is important.
What is also good with Azure is that it uses service principals for controlling access to these resources, so we don’t use username or passwords to run jobs or scripts.
If you have long lived access tokens, API keys, or passwords that need rotating, you might want to consider automating this outside of Postman. We have the capability to run PowerShell scripts through Azure runbooks on a scheduled basis to update these elements. These scripts run with a service principal that has read\write access to the relevant key vault.
I think I get this, and storing confidential information (secrets, keys) as “secrets” within the current values of the Environment variables is what we’re currently doing. We copy & paste from our keyvault, and every person in the team needs to do this as we’re not syncing secrets & keys in the cloud.
What I’m specifically asking about is the access_token, typically those that last from 5mins > 60mins, which we would generate/request either on a timed basis or every time we make a request.
Would you recommend storing those in an Environment variable too, or Collection, or Global?
Those are short lived, so they won’t need to be in the key vault. (The client_id and client_secret that is used to generate the token should be).
If I’m already using environment variables for other values, then I would store them as environment variables. They are still confidential information, so it still should be current values in environments.
If you are using the new Postman CLI, you are running the collection directly from the cloud, so it might save any variable that are set, which would include any collection variables. I don’t use the CLI so I haven’t tested or confirmed this. I don’t know if the execution of the collection is read only.
If you were running this locally using Newman, then they could go as any scope really, as they will only exist for the duration of that execution, but when you are creating\defining the collection using the GUI, you will potentially be saving it to the cloud.
TLDR: Use current values within environments, the same as any other confidential value.