Those details, app secret and token are confidential bits of information.
Therefore they should only exist locally in the current value field.
This means they don’t get synced to the Postman Cloud, or included if you export the collection\environment as a JSON file to be included in your code repository.
We would normally store these details centrally in a key vault or similar product.
It’s then a cut and paste job when you want to run the collection locally.
This is a pain if you have a short lived token that expires frequently.
It can be automated as part of the CLI. One of the first steps in the pipeline would be to retrieve the relevant secrets from the key vault and send these as environment variables in the Newman command line.
I don’t generally use the Postman authorization helper for tokens.
I have a pre-request script at the collection level that will generate a new token if one doesn’t already exist as an environment variable and the expiry date has not passed. This is using sendRequest() instead of the helpers.
The details used to produce the token, client secret, etc are still stored in a key vault, and you still need to copy that locally to the current value in the environment.
This works ok for us as there are no limitations on most of our API’s around how often you can generate a token. This would be an issue if there were limitations on who and how often you could generate a new token.
To be truthful, I probably don’t even need to look at the expiry date, I could just generate a brand new token on each collection run. If your tokens only last for an hour, would it be an issue to just generate a new token on each collection run?