Introduction To OAuth 2.0
This article provides an overview of OAuth 2.0 technology. It will help you understand what OAuth 2.0 is, how it works and why it will be beneficial.
Last updated
This article provides an overview of OAuth 2.0 technology. It will help you understand what OAuth 2.0 is, how it works and why it will be beneficial.
Last updated
This article provides an overview of OAuth 2.0 technology. It will help you understand what OAuth 2.0 is, how it works and why it will be beneficial.
If you're unfamiliar with OAuth 2.0, we recommend that you read this article for context before you try and integrate Google, Facebook, Microsoft or other Authorization technologies into your Dittofi app.
To explain OAuth 2.0 let's start with the case of a developer Greg.
Greg is developing a custom social media app called WeSocial. One day Greg's boss tells him that he needs to add a new feature to WeSocial. The new feature will allow users to login to WeSocial with Google's single sign on feature. What this means is that Greg is going to delegate the role of user authorization to Google, rather than managing them on its own.
After a quick Yahoo search, Greg reads that the Google single sign on uses OAuth 2.0. Before trying to implement something that he knows nothing about, Greg decides to first read the rest of this article to learn what OAuth 2.0 is all about.
Greg starts by reading about "What are the roles in OAuth 2.0".
To understand how OAuth 2.0 works, let's start by looking at some of the high level roles that exist within an OAuth 2.0 framework. For simplicity we will use three roles to start: the user, the application and the API (Application Programming Interface).
Because of the growing popularity of OAuth 2.0, you've most likely seen the use of OAuth 2.0 in your everyday internet use. For example, when you launch Spotify to listen to your music, you may have chosen the option to login with Facebook. In this case, Spotify is the application and Facebook is the API.
When you login to Spotify via Facebook, Spotify will request access to your basic user information and profile picture.
Now, for Greg's case, it is his WeSocial application and not Spotify and instead of Facebook, he intends to use the Google API.
Now Greg has read this, he is thinking:
"Wow okay, I get it. So when I log into Spotify, Spotify will go and get my username and password from Facebook... it's so easy."
BUT THIS IS WRONG. THIS IS NOT WHAT HAPPENS AT ALL.
Greg's trail of thought is is one of the biggest and most common misconceptions about OAuth 2.0 frameworks... let's see what really happens.
** IMPORTANT **
Passwords are never passed from server to server during the OAuth 2.0 framework.
Let's use Greg's WeSocial app as an example and let's walk through how one of his apps users, Gloria, can sign up and login to WeSocial using the Google API.
To do this, Gloria needs to open up the WeSocial app and clicks to login to the app via Google.
<insert image>
When Gloria clicks to login to WeSocial using Google, WeSocial will make an Authorization Request to the Google Authentication Server.
The Google Authentication Server will then display to Gloria a Google authorization screen asking her to authorize WeSocial to access certain personal information stored inside Google.
You may recognize these types of screens from other use cases, where a prompt will tell you what permissions an application is requesting. In our Spotify Example, Facebooks authorization screen asks you to authorize Facebook to send Spotify your public profile, friend list, email address and birthday. An example of this is shown below.
Back to Gloria, Gloria grants permission to WeSocial to receive certain personal information that is stored on the Google servers. Google then send WeSocial an Authorization Grant and an Authorization Code that WeSocial will use when requesting an access token to see Gloria's personal information.
** IMPORTANT **
Notice that at no point in this process has a password been passed between the Google authentication server and the WeSocial app. The only information to have been passed so far is an Authorization Grant and an Authorization Code.
Here is where we come to the distinction between the Authorization Server and a Resource Server.
WeSocial is going to take Gloria's Authorization Grant and Authorization Code and use this to request access to an Authorization Token stored on the Google Authentication Server.
Note that none of Gloria's profile picture or other private data is stored on the Google Authentication Server. The Google Authentication Server is ONLY responsible to authorizing Gloria as a user and providing the proper Access Token that will eventually allow WeSocial to retrieve her protected information from the Resource Server.
After accepting the Authorization Grant and Authorization Code that WeSocial provided on behalf of Gloria, Google's Authentication Server provides WeSocial with an Access Token specifically for Gloria. The image below shows the Google Authentication Server returning the Access Token.
The Access Token will be included in all requests from WeSocial to Googles Resource Server and it provides WeSocial with access to whatever information Gloria granted permission to see.
Finally, WeSocial sends a request to the Google Resource Server with the Access Token included, and Google identifies that this Access Token is valid to access those particular pieces of Gloria's Google account.
The Google Resource Server then sends this protected information back to WeSocial and WeSocial now has Gloria's information to display.
Notice that throughout this entire framework, OAuth 2.0 serves as the authentication framework. The actual authentication of Gloria as a user occurs with Open ID Connect.
In order for all of this to work though, our developer Greg needed to register his WeSocial application with the Google API service. Independent of any user involvement, Greg needs to provide the Google API with WeSocials name, website and the URL callback to which Google will send the user after they have clicked to accept (or reject) WeSocial on the Google Authorization screen.
Once WeSocial has supplied the name, website and URL callback information to the Google API service, Google will send back a set of credentials to WeSocial. These credentials include:
A Client ID which, is a public and unique identifier that will be used to identify WeSocial as an application
A Client Secret which, is a private identifier kept secret between the WeSocial app and the Google API. The Client Secret is used to authenticate WeSocial when it makes a request for an access token.
REMEMBER
Before Greg can start developing he needs to first register his WeSocial app with the Google API.
While Greg is registering his app, WeSocial, Greg needs to decide which of Gloria's protected resources he is going to ask for access to.
Greg also needs to provide a redirect URL to the Google API, to let the API know where to send WeSocial's users when they have given permission to WeSocial to access their protected resources.
Once Gloria has authorized WeSocial to access her protected information, WeSocial will get an Access Token that it can use to get the protected information out of the Google Resource server.
Now that you know what OAuth 2.0 is and how it works you can start building OAuth 2.0 integrations using Dittofi. These will allow you to quickly augment your apps with advanced functionality that has already been developed by tech companies.
A good starting point here is to look at the documentation for Google OAuth 2.0 and to set this up inside Dittofi.
