OAuth is one of the fundamental API building blocks, providing authentication and authorization for the resources that APIs deliver behind web and mobile applications. But while OAuth is a ubiquitous security measure, it is also one of the top points of friction for developers.

Because there are still many different ways to implement OAuth, it means there are numerous challenges developers can face when integrating APIs into applications and other systems. In response, Postman is continuously figuring out new ways to adjust for these different variances in how OAuth is implemented and remove OAuth friction.

To highlight the recent work we’ve done to make OAuth easier for developers, we want to share some of the improvements Postman engineers have made as a direct result of Postman community feedback. Here are six OAuth enhancements to Postman that we introduced over the last four releases—all in response to GitHub issues submitted by our users:

Postman v7.27

  • In response to GitHub issues #4727, #6616: We added support for using a custom Authorization header prefix in OAuth 2.0. This gives developers more control over the headers they need to pass with each API request.
  • In response to GitHub issues #283, #783, #1240, #2302: We added callback and verifier fields with body hash support in OAuth 1.0 to help resolve the friction encountered with APIs still dependent on the older version of the spec.

Postman v7.26

  • In response to GitHub issue #6115: We expanded user capabilities when managing OAuth 2.0 tokens, giving the option to delete all or just the expired tokens. This further helps teams effectively manage tokens as they age.

Postman v7.25

  • In response to GitHub issue #7700: We fixed an issue in which OAuth 2.0 and sign-in were using an older version of Chrome. This addresses the role that our browser plays when it comes to doing the OAuth dance.

Postman v7.24

  • In response to Github issue #7952: We fixed a bug in the Postman Console that wouldn’t log intermediate requests while generating OAuth 2.0 token. This increases the visibility that developers have into what is going on across the APIs their teams are using.
  • In response to Github issues #7700, #8059: We opened up the ability to use an external browser for authentication while generating OAuth 2.0 tokens. This addresses the role that our browsers play and helps ensure that Postman is able to work with all APIs that are using OAuth.

We’re continuously striving to make Postman an essential tool in the developer toolbox for troubleshooting and working around common OAuth challenges, but we couldn’t do it without our fantastic user community. We want to thank every developer who submitted a GitHub issue to us to describe the friction they experienced. Without this type of feedback, we wouldn’t be able to keep expanding Postman for developers to be more successful in working with OAuth-enabled APIs.

Do you have any tips for—or interesting experiences—working with OAuth? Share your insights in a comment below.