I’m using OAuth2.0 in AuthN tab and manually able to generate the access token by clicking “Get New Access Token”. As I set the authorization data to go to request header, it automatically sets the value of the auth header with this token. But I’m unable to change the key of the auth header. Its defaulting it to “Authorization” when my application expects something like “x-access-token”. Couple of questions:
How can I change the key of the default header?
How to auto store the resulting accessToken to an environment variable so this can be reused by multiple requests across various collections?
FYI, I’m using grant type as "Authorization Code (with PKCE) and auth process involves SSO with Azure AD, so I have to manually enter my credentials in the popup window. As my token is short lived, presently I generate the token by clicking “Get New Access Token” button, manually copy the resulting token to an env variable. Looking for any way to automate this.
I tried this code in Tests tabs and obviously did get executed when clicking this button
var res = pm.response.json();
pm.environment.set('jwt-token', res.data.access_token);
Thanks for reaching out. Let’s try to take this step by step:
Changing the Default Header Key:
When you retrieve an OAuth 2.0 token in Postman, the default behavior is to set the token in the Authorization header. Currently, Postman doesn’t support automatic customization of this header key through the “Get New Access Token” view. As a workaround:
After obtaining the token, go to the Headers tab of your request.
Manually change the Authorization header key to x-access-token or any other custom header your API expects.
Automating the Storing of Access Tokens:
As you’ve pointed out, the script you placed in the Tests tab doesn’t execute when obtaining a new token using the “Get New Access Token” view.
To automate this process, you might consider setting up a dedicated Postman request that directly interacts with your authentication server to obtain the token. This way, you can leverage the Tests tab script to parse the response and set the token as an environment variable.
Using Refresh Tokens & Handling Token Expiration:
If your OAuth 2.0 server returns a refresh token, it’s wise to leverage it, especially with short-lived access tokens.
Within Postman’s OAuth 2.0 setup in the Auth tab, ensure you’ve populated both the “Access Token” and “Refresh Token” fields.
You can create a pre-request script across your collection or individual requests to check if the token is about to expire. If it is, use the refresh token to obtain a new access token before executing the main request.
Automation with Azure AD and SSO:
It’s a challenge when systems like Azure AD, which involve Single Sign-On (SSO), require manual input. I understand the inconvenience, especially given the short-lived nature of your token.
You might want to explore other Azure AD grant types or flows that allow token retrieval without interaction. If your security protocols allow it, a grant type not requiring SSO could streamline your testing in Postman.
