OAUTH2 & GOOGLE API PART II
In the first part of this article we have seen an introduction regard some basic concepts of this industry-standard framework called OAuth 2.0 (Open Authorization), a framework for authentication and authorization based on Tokens. We also went through an exercise of coding an example (using Gmail API Service and NodeJS) of one of its authorization grant type, the Authorization Code (a three-legged authentication scenario).
Now, at this Part II of our OAuth 2.0 journey, we are going to code an example of the two-legged authentication scenario using the Client Credentials grant type, one of those available by the specification. (See the little theoretical introduction of OAuth 2.0 framework at the Part I, in case you are not understanding very well what we are saying here).
Let’s use the Google Cloud Pub/Sub API Service to write our example, simulating our Application (playing the role of “Client” 3rd-Party Application), using the services provided by this API. Just for a matter of better understanding, and also in order you don’t need to go back to Part I and see what is (and the purpose of) the Google Cloud Pub/Sub API, we will put here the little presentation of it, the same written before:
Google Cloud Pub/Sub API Service (https://cloud.google.com/pubsub/)
- This Google Cloud Service is an event base data stream system, useful to exchange information between consumers and providers in a stream using the very old (reliable and scalable) concept of messaging. It is not a surprise that the name of this cloud service is Pub/Sub. That rings a bell, doesn’t it?
- In order to be able to use this API Service, we need before require the authorization (as well perform the authentication) and for this happens, we will use the OAuth 2.0 through the Client Credentials authorization grant type, provided by the Google Cloud Pub/Sub API Service.
Client Credentials Authorization Grant Type
As stated before, now at this scenario we are going to use the two-legged authentication, a typical scenario where it is not possible, or not convenient, to have the presence of the “User” (Resource Owner), to give the consent of the authorization all the time, in a online manner. As in a Server-to-Server communication… imagine that part of your Application needs to interact with some API Service to perform a job, on behalf of the user, at some time that he/she is not present, a scheduled job for instance at three o’clock in the morning, or a event-based communication (that triggers some action when something happens, like a message being received in a queue).
It is worth to mention (again)… as we said at the Part I regarding Client Credentials that: this authorization grant type is typically used when the “Client” (3rd-Party Application) is also the “User” (Resource Owner), and it is performing an action on its own behalf, or… is requesting access to protected resources based on an authorization previously agreed with the “API Server” (Authorization Server).
Revisiting the generic flow of this framework, in this scenario the communication would go like this:
Having said all that, let’s use the Client Credentials authorization grant type in our example.
But, wait! Before dive into our code we have to perform some steps, in order that our Application be able to use the Client Credentials grant type, with the Google API Service. We need to create another type of credential at the Google Developer Console API, we need to create a Service Account.
The whole article, source code and everything else, available at...
https://ualterazambuja.com/2017/09/21/oauth2-google-api-part-ii/