Google Authentication with Postman
As a back-end developer I spend a lot of my time working with a veritable cornucopia of APIs from many different providers. To understand how these APIs work I tend to make use of Postman.
Postman is a seriously useful program for building APIs and interacting with existing APIs. Many of the APIs I use tend to require the response of one call to be fed into the next call and Postman allows you to achieve this with ease (perhaps the subject of another blog post?). Basically I can’t recommend it enough!
My recent development time has involved working with Google APIs. Google APIs require authentication which essentially boils down to you providing a bearer token. These bearer tokens are short lived and tend to require frequent regeneration. As you can imagine, this gets tedious fairly quickly when sending API requests to your endpoint.
In this post I will detail three different mechanisms for generating bearer tokens so you can interact with Google APIs using Postman.
- Using oauth2l CLI
- Configuring Postman with OAuth 2 and User Credentials
- Configuring Postman to use a pre-request script and service credentials
Using oauth2l CLI
This handy CLI utility allows you to generate bearer tokens which can be pasted into the Authorization header in postman. This tool supports GCP generated credentials or can hook into your existing Google Cloud SDK session. This mechanism can use user credentials or a service account for authorisation.
Using oauth2l is a manual process and fine for a few simple oft-used calls but when the bearer tokens expire you need to manually regenerate them and update your Authorization header with the new token. It does, however have the benefit of being quick and easy to setup.
Configuring Postman with OAuth 2 and User Credentials
Postman can be configured to trigger the OAuth 2 flow and use a generated bearer token in all of your requests. This uses user credentials rather than a service account so you’ll need to make sure that any users will have the relevant permissions in the GCP project.
OAuth 2 credentials need to be created in Google Cloud Console. This is configured on a per-project level.
You’ll need to add an Authorized redirect URI in the above screen. This doesn’t need to resolve to anywhere however.
The Client ID and Client Secret need to be saved to your machine for use in a moment.
The best way to use this mechanism is to use Postman’s environment variable functionality. This allows you to use different credentials per environment/project.
In Postman create a new environment for your credentials using the cog icon at the top right:
Configure the variables accordingly:
AUTH_CALLBACK_URLThis variable should be identical to that defined in the OAuth 2 Client ID creation menu.
AUTH_SCOPEThis variable should be one of the following:
https://developers.google.com/identity/protocols/oauth2/scopes
Multiple scopes can be specified, delimited by the space character.
AUTH_CLIENT_ID and AUTH_CLIENT_SECRETThese variables are the ones you saved from the OAuth 2 Client ID and secret screen. The Xs below are just to hide my secrets ;-)
Your environment variable screen should look something like this:
Once defined, these variables can be used in your Authorization tab in Postman. This can be configured at the collection level, the folder level or even the individual request level.
Click on “Get New Access Token” button.
The variables defined above should be used in this dialog.
{{AUTH_CALLBACK_URL}}
{{AUTH_URL}}
{{AUTH_ACCESS_TOKEN_URL}}
{{AUTH_CLIENT_ID}}
{{AUTH_CLIENT_SECRET}}
{{AUTH_SCOPE}}Once the variables have been configured, Click on “Request Token”. You will see the sign in screen as shown below (if everything is configured correctly).
Login using your Google credentials and you should see that a bearer token has been generated for you.
This bearer token will eventually expire and you’ll need to request another token to continue using this API. Tokens can be managed via the Postman UI and expired ones cleaned up at the click of a button.
Requests in this collection will have an auto-generated Authorization header.
Configuring Postman to use a pre-request script and service credentials.
This is my preferred mechanism. The pre-request script automatically regenerates the bearer token when it expires so you never have to worry about your requests failing with a 403. Authentication happens using a service account rather than user credentials.
It’s slightly more complicated to configure but I believe that it’s worth the slight effort at project setup. When using the postman collection in future, it’s much simpler as you no longer need to be concerned with periodically refreshing the bearer token.
This mechanism is based on the sterling work of Denis Loginov, the gist is available here:
This code is stored in the Pre-Request Scripts section of Postman
The SCOPES variable needs to be configured accordingly (See here for reference).
The contents of the service JSON credentials file from the Google Cloud Console needs to be stored in the environment variable serviceAccountKey.
This can be generated for your service account in the Google Cloud Console:
For each request, the code checks to see whether the token has expired and if so a token is generated and stored in the accessToken environment variable. This can be utilised in the Authorization tab of Postman.
Summary
I’ve detailed three different mechanisms for interacting with Google APIs, all of which have their advantages and disadvantages. I tend to use the third method for my projects as I like things to be as easy to use as possible; there is enough complexity in code without worrying about constantly expiring bearer tokens ;-)
I hope that this blog helps you a little when using Postman with Google’s awesome APIs.
