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