OAUTH2 & GOOGLE API PART I

OAuth 2.0, commonly pronounced “oh-auth”, is an industry-standard framework for *authentication and *authorization based on tokens. The OAuth (Open Authorization) delegates to a Service to allow a third party Application to access user account information on behalf of him(her), with their previous authorization.

It is, indeed, a little bit boring the formal explanations that we usually found when googling “what the h… is OAuth”, and also how this framework works. So… let’s try to make the theoretical part a little short, direct and easy to understand, with some drawings and short explanations. This way, and still with enough theoretical content, we can slip faster to the enjoyable part: the sample coding.

We already mentioned what is OAuth2 at the beginning of this article, you wanna hear again? In only three words? An industry-standard framework, that’s it! The rest, and the most important, is more about to know how it works and how to implement (to use it in your day-to-day design solutions needs).

Now speaking in a more formal tone… For a long and complete OAuth 2.0 site theory source, check its IETF specification: RFC-6749. It’s also very useful to keep it in mind when some doubts come up. It is important to mention that this is a specification that (as much of them) do not define all the very thin details of the discussed technology implementation. So, that’s why it is likely and easy to find some deep differences between two distinct proprietary implementations of this same framework, the OAuth 2.0. I suggest you to have some of the most basic important concepts of what is, what can you do with it, how it basically works, and then… go deeper to the docs and manuals of the provider (Google, Facebook, LinkedIn , etc.) of some the API, that is built using a implementation of this framework specification.

Ah! before going on, one more thing… everything that we discuss here is about OAuth 2.0, even though you found only the word OAuth, I meant OAuth 2.0. The OAuth 2.0 is not backwards compatible with the OAuth 1.0.

*AUTHENTICATION IS A PROCESS THAT ANSWER A SIMPLE QUESTION: ARE YOU, IN FACT, WHO YOU ARE SAYING WHO YOU ARE?

IN SIMPLE TERMS: ARE YOU REALLY YOU?

*AUTHORIZATION IS A PROCESS THAT ANSWER A SIMPLE QUESTION: ARE YOU ALLOWED TO PERFORM THESE TASKS OR ACCESS THOSE INFORMATION?

IN SIMPLE TERMS: DOES YOUR MOTHER (OR WIFE, OR BOTH) LET YOU DO THIS?

THE CHARACTERS

Third-Party Application or simply the “Client”

This is the application who needs to get access to the Users Account, the “client” who starts everything. It is for whom the users allow access to their account information. Hereafter, let’s also call it: “Client”.

The Resource Owner or simply the “User” ( that’s usually You! )

This is the person who is giving the access to some portion of their account. That’s you behind the term Resource Owner, let’s also named here, “User”.

The Resource Server or simply the “API Server”

This is the server that has the protected resources belonging to the users. It will only deliver information to the “Client” when a valid token were presented together in the request. Hereafter, let’s also identify it: “API Server”. An example of a “API Server”? Facebook, Google, Twitter, Microsoft, GitHub, Instagram, LinkedIn, PayPal, Amazon, Evernote, …

The Authorization Server or simply the “API Server”

This is the server that approves or denies the request of the “Client”. Usually responsible for provides an interface to the “User” (character) to perform this authorization.

Have you noticed? We are calling both the Authorization Server and the Resource Server of “API Server”. That’s because this role is almost always played (in reasonably small implementations) by the same character, that is, a Provider. Like we have already mention before: Facebook, Google, Twitter, etc, those might be the Authorization Server, besides also being the Resource Server. Let’s named them of “API Server”.

THE FLOW

The details of the sequence of events of how this framework behaves, it depends on the authorization grant used, but there is a generic flow that we can pretty much understand how is supposed to work according to its implementation, let’s see it:

THE BADGE (AUTHORIZATION GRANT)

The authorization grant it is the credential, that represents the “User” (Resource Owner) authorization, used by the “Client” (3rd-Party Application) to obtain an Access Token. That means… that’s the invitation given by the user for you to be able to join the party. Without it, you cannot go any further. On the contrary… if the user “invites” (authorize) you, then you will have a badge (Access Token) to access some parts of his “home” (will be able to access their account information). There are four grant types useful for different use cases, let’s see some of its basics according to the specification RFC-6749:

The whole article, source code and everything else, available at...

https://ualterazambuja.com/2017/09/21/263/

?