What we need to know about OAuth
Have you recently visited a site or application, where you are given the option of connecting or sign in using Google, Facebook or Twitter? Sure you have! But are you aware of the mechanisms behind this? Or if you are implementing an application or site instead of having a custom login, do you want to use Google, Facebook or Twitter to authenticate your application or website?
The mechanism behind for those is OAuth. So what is OAuth, what are the versions of OAuth, what are the roles, endpoint and grant types of OAuth2? For all these questions I am going to give you the answer in this post. And also in the laster part of this post, I will explain how to implement an application with OAuth.
Introduction
There are two versions of OAuth: OAuth 1.0 and OAuth2. These specifications are completely different from one another, and cannot be used together. There is no backwards compatibility between them.
In December 2007, OAuth 1.0 addressed delegation with a framework based on digital signatures. It was secure and it was strong. By 2010, Twitter forced all third-party apps to use their OAuth 1.0 implementation. However, OAuth 1.0 required crypto-implementation and crypto-interoperability. While secure, it was a challenge for many developers to implement. Then came OAuth 2.0 in October 2012. Which made the implementation easy for the developers.
What is OAuth?
In simple words, OAuth (Open Authorization) is an open standard for token-based authentication and authorization the Internet.
Authentication is the process of determining whether someone or something is, in fact, who or what it declares itself to be.
Authorization is the process of giving someone permission to do or have something.
The OAuth 2 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of the resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
From the below chart you can get a clear idea about the differences between the OAuth 1.0 and OAuth2.
How does OAuth work?
Before getting into how OAuth2 works we need to understand roles, endpoints and grant types.
Roles
· Resource owner: An entity capable of granting access to a protected resource. When a resource owner is a person, it referred to as an end-user.
· Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource requesting access tokens.
· Client: An application making protected resource requests on behalf of the resource owner and with its authorization.
· Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Endpoints
· Authorization Endpoint: Used by the client to obtain authorization from the resource owner via user-agent redirection.
· Token Endpoint: Used by the client to exchange an authorization grant for an access token, typically with client authentication.
· Redirection Endpoint: Used by the authorization server to return responses containing authorization credentials to the client via the resource owner user agent.
Grant Types
The term “grant type” refers tot he way an application gets an access token. OAuth2.0 provides different options by various Grant types such as,
· Authorization Code Grant: Used for server-side applications.
The authorization code grant type is used to obtain both access token and refresh tokens and is optimized for credential clients.
· Implicit Grant: Used with mobile apps or client-side web applications.
The implicit grant type is used to obtain access tokens and is optimized for public clients known to operate a particular redirection URI. Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request. The implicit grant type does not include client authentication and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.
· Resource Owner Credential Grant: Used with trusted Applications, such as those owned by the service itself.
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
· Client Credential Grant: Used when the registered user wants to obtain token for itself.
The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server (the method of which is beyond the scope of this specification).
· Refresh Token Grant: Used to refresh expired access tokens, by passing the refresh token.
Some of the vulnerabilities in OAuth2,
· Overwriting URL redirect in a mobile application.
· Using OAuth2 implicit flow for authentication.
· Service provider not verifying authorization code.
· Not using session token vulnerability.
· Web view vulnerability.
So now let us implement an application with OAuth. I am going to explain how to create a Google Drive App in flask.
Creating a Google Project
- First go to the Google Developers Console. Sign in using your Google credentials if you haven’t already sign in.
- Click on the Select a project to create a new project.
3. From the prompt that opens up click on “New Project”.
3. Give a name to your project and click on the Create button.
4. Once you successfully created the application you will directed to the following project page.
Configuring the Credentials
- Click on the Enable APIs and Services or Google Drivers App to enable the API.
2. Afterwards, you will be redirected to the below page. Click on Enable button.
3. Now in order to use this we need to create credentials. Select the Create Credentials or Select the Credentials->Create Credentials from the side menu.
4. Select the API as GoogleDrive API,Web server and User Data. Then click on the What credentials do I need? button.
5. Afterwards, you will be directed to the following page. Set the authorized redirect URIs correctly, so that the google can redirect users to the app once they grant permissions to it.
Its important that the URI should be secure(https), unless they are set to localhost for testing.
After setting the relevant details, click on the Create OAuth client ID button.
6. Then you will be directed to the following page. In here the consent page details that will be set up.
7. The client ID will be displayed in here. Download and save it ass client_id.json in the same directory as the flask app.
Create the back-end app
First install Google API client library for python.
pip install flask google-api-python-clientThe let’s create a flask object and handle the home page url to do the OAuth authentication on the behalf of the logged in user.
Create a credentials.json file and save it in the same directory. The drive access credentials for the user is checked using the get_credentials() from the credentials.json file. Further, if credentials aren’t found locally or have expired, we direct them to /oauth2callback, so google will authenticate them and send us the token for accessing the drive, post which, we will put that token into the local file, credentials.json and redirect the user back to this index site. Finally, if the credentials are valid, we call the fetch() that displays the list of all root folders in that user’s drive along with their IDs. Here is the code for /oauth2callback
Before you run the application make sure that the client_id.json and the credentials.json file is in your directory.
If you have done the steps correctly, when you run your application, the following screen will be displayed.
Once you Allow access the application you can view the Google Drive file for your account.
How to identify what grant type to be used?
This diagram will help you to identify what grant type you should use for your application according to your requirement.
Conclusion
I hope the world of OAuth is more clear now that you read this article, my goal was to explore the basics of this protocol. The full implementation of this application can be assessed in my GitHub account. So have fun in using OAuth.
Also download and upload files for the drive is also included in the GitHub project.
