In the script, I’m using Postman’s global variables to track some important things, including the client_id, client_secret, and grant_type, which I need for the body of the authorization request. So what’s going on here? I’m taking advantage of a few things. This is what I have in my collection’s “Pre-request Scripts”: We can take advantage of this to make sure we always have a valid token before requests. You may have noticed that when editing the Collection, alongside the Authorization tab there was a tab called Pre-Request Scripts. It was annoying to continually get a new token through the process above. On my project, the token would expire after fifteen minutes - enough time to get the token once and try out a few requests, but a pain for longer sessions. This is all well and good, but there’s one catch: our token can’t automatically refresh. The only remaining step is to ensure that each request needing authorization is set to inherit auth from parent (meaning the collection): If we plug in our appropriate credentials and click “Get New Access Token” and then “Update,” we’ll be all set up for our requests. After right-clicking to edit our Collection and navigating to the Authorization tab, we can select the OAuth 2.0 type from the dropdown and be presented with this: In our Postman Collection, we can take advantage of collection-level authorization so that we don’t have to configure it request by request. On my project, we have an API that grants and uses OAuth2 access tokens for authentication (with no refresh token). Here’s a solution I found that works well. The more I’ve used it, the more ways I’ve tried to tackle this problem. One challenge with Postman is deciding how to authenticate your requests, something I’ve dealt with on a recent project. Like many others, I like to use Postman when building and testing an API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |