API authorization is a top concern at Postman.
We’ve always built features to help you manage authorization for your protected resources, such as using environment variables with authorization types, saving authorization types to collection requests that generate a signature each time, and using authorization types in Newman.

But we realized we needed to do more. API authorization can be a complex process for any user, no matter the experience level. We listened to our users’ pain points—frustration when requests fail due to stale authorization headers, not enough authorization types, too many calls to complete authorization for a request, and their desire to understand authorization types and what they require. To address these pain points, we decided to overhaul our authorization schema to make it easier for newbies, advanced users, and everyone in between.

Note: These authorization additions and improvements are only available in Postman native apps.

Request authorizations

In version 5.3, Postman automatically saves authorization information with the request. Postman will always use this saved information to ensure Postman does not add or use stale authorization in the request.

Authorization signatures

In version 5.3, Postman no longer saves authorization headers and parameters in a request. This behavior prevents exposure of sensitive information when you share the request, and maintains up to date request data.

Authorization types

We have introduced two new authorization types to give you more options: Bearer Auth and NTLM Auth. We’ve also improved the behavior of Digest Auth, OAuth 1.0, OAuth 2.0, and Hawk Auth.

Bearer token authorization

A bearer token is a security token. Any user with a bearer token can use it to access data resources without using a cryptographic key.

NTLM authorization

Windows Challenge/Response (NTLM) is the authorization flow for the Windows operating system, and for stand-alone systems. By default, Postman extracts values from the received response, adds it to the request, and retries it. Postman gives you the option to disable this default behavior.

OAuth 2.0 grant types

We’ve introduced two additional grant types for OAuth 2.0: implicit and password credentials. We added these grant types to help users who have not been able to use OAuth 2.0 with Postman.

Postman attempts to bridge the gap for generating new tokens with major providers, but all providers are not the same. With these additional grant types, more users will be able to use OAuth 2.0 in Postman. If you've not used OAuth 2.0 in Postman recently, we encourage you to try it again with these grant types. In addition, we provide a manual option to add any token to a request.

Digest authorization

In version 5.3, Postman automatically fetches properties from the first attempt and retries the second attempt to authorize a request.

Note: You must remove values from previous versions before Postman 5.3 can automatically fetch properties.

OAuth 1.0 and Hawk authorization

In version 5.3, Postman continues to automatically generate timestamp and nonce values. But now it generates these values each time those fields are empty.

OAuth 2.0 authorization

In version 5.3, you must enter the callback URL from your provider when you received your client ID and client secrets. Postman automatically intercepts any callback URL when the authentication provider redirects to the same URL.

Header and query parameters

In version 5.3, Postman automatically adds header and query parameters to your outgoing request, but it doesn’t save them in your original request. Instead Postman shows these as preview headers and you now have the option to select the headers you want to save with your request.

API authorization is a top concern at Postman. We’ve always built features to help you manage authorization for your protected resources, such as using environment variables with authorization types, saving authorization types to collection requests that generate a signature each time, and using authorization types in Newman. But we realized we needed to do more. API authorization can be a complex process for any user, no matter the experience level. We listened to our users’ pain points—frustration when requests fail due to stale authorization headers, not enough authorization types, too many calls to complete authorization for a request, and their desire to understand authorization types and what they require. To address these pain points, we decided to overhaul our authorization schema to make it easier for newbies, advanced users, and everyone in between. Note: These authorization additions and improvements are only available in Postman native apps. Request authorizations In version 5.3, Postman automatically saves authorization information with the request. Postman will always use this saved information to ensure Postman does not add or use stale authorization in the request. Authorization signatures In version 5.3, Postman no longer saves authorization headers and parameters in a request. This behavior prevents exposure of sensitive information when you share the request, and maintains up to date request data. Authorization types We have introduced two new authorization types to give you more options: Bearer Auth and NTLM Auth. We’ve also improved the behavior of Digest Auth, OAuth 1.0, OAuth 2.0, and Hawk Auth. Bearer token authorization A bearer token is a security token. Any user with a bearer token can use it to access data resources without using a cryptographic key. NTLM authorization Windows Challenge/Response (NTLM) is the authorization flow for the Windows operating system, and for stand-alone systems. By default, Postman extracts values from the received response, adds it to the request, and retries it. Postman gives you the option to disable this default behavior. OAuth 2.0 grant types We’ve introduced two additional grant types for OAuth 2.0: implicit and password credentials. We added these grant types to help users who have not been able to use OAuth 2.0 with Postman. Postman attempts to bridge the gap for generating new tokens with major providers, but all providers are not the same. With these additional grant types, more users will be able to use OAuth 2.0 in Postman. If you've not used OAuth 2.0 in Postman recently, we encourage you to try it again with these grant types. In addition, we provide a manual option to add any token to a request. Digest authorization In version 5.3, Postman automatically fetches properties from the first attempt and retries the second attempt to authorize a request. Note: You must remove values from previous versions before Postman 5.3 can automatically fetch properties. OAuth 1.0 and Hawk authorization In version 5.3, Postman continues to automatically generate timestamp and nonce values. But now it generates these values each time those fields are empty. OAuth 2.0 authorization In version 5.3, you must enter the callback URL from your provider when you received your client ID and client secrets. Postman automatically intercepts any callback URL when the authentication provider redirects to the same URL. Header and query parameters In version 5.3, Postman automatically adds header and query parameters to your outgoing request, but it doesn’t save them in your original request. Instead Postman shows these as preview headers and you now have the option to select the headers you want to save with your request.
edited Nov 28 '17 at 6:25 pm
 
0
reply
45
views
0
replies
1
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft