Postman makes authorization stronger and easier

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.

We’re excited to announce additional authorization types and OAuth 2.0 grant types with the release of Postman version 5.3. We’ve also improved behavior for request authorizations, authorization signatures, existing authorization types, and managing header and query parameters.

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

Let’s take a look at these authorization changes in Postman 5.3.

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.

In previous versions, Postman didn’t save authorization information in a request, unless you indicated so in the “Save helper data?” checkbox.

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.

In previous versions, Postman saved authorization header and parameter signatures with the request. When you sent the request, you were actually using the signature computed the last time. In version 5.3, Postman always computes the signature before you send the request and doesn’t save it.

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.

In previous versions, Postman saved those values to the request. As a result, the next request contained stale values.

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.

Note: You must remove any headers and query parameters from previous versions before Postman 5.3 can automatically generate those parameters. Postman displays a warning before overriding a header.

Tip: As noted previously, these authorization changes are only available in Postman native apps. However, you might be able to use the Postman Chrome app to edit a collection and save the headers.