Develop Facebook App using OAuth

This blog is to explain the development of the Facebook Application with “OAuth” using to retrieve the resources of the user. The proposed application is a JAVA web application developed in MAVEN.

Before going to the implementation, we learn about some related stuff of OAuth.

What is OAuth?

OAuth is an open authorization protocol, which allows accessing the resources of the resource owner by enabling the client applications on HTTP services such as Facebook, LinkedIn, GitHub, etc. It allows sharing of resources stored on one site to another site without using their credentials. It uses username and password tokens instead.

Why use OAuth?

• You can use OAuth to read data of a user from another application.
• It supplies the authorization workflow for the web, desktop applications, and mobile devices.
• It is a server-side web app that uses authorization code and does not interact with user credentials.

OAuth Roles

• Resource Owner
• The resource owner is the user who authorizes an application to access their account.
• Client Application
• The client application that wants to access the user's account.
• Authorization Server  
• The authorization server verifies the identity of the user then issues access tokens to the application.
• Resource Server
• The resource server hosts the protected user accounts.

Authorization Grant

The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the API.

OAuth defines four grant types, each of which is useful in different cases:

• Authorization Code: used with server-side Applications.
• Implicit: used with Mobile Apps or Web Applications.
• Resource Owner Password Credentials: used with trusted applications.
• Client Credentials: used with Applications API access.

We will develop the server-side JAVA web application. So, we are used Authorization Code grant type for authorization. Now we will describe the authorization code flow in detail.

Now let’s see how to build up, deploy and run Facebook Application with “OAuth”.

First, we need to create a web application on Facebook.

Go to Facebook for developers https://developers.facebook.com/

After login, click Add New App link under My Apps menu.

Then, we need to mention the App Domains as localhost in Basic Settings.

Then, add a Facebook Login product and enter the Valid OAuth Redirect URIs.

A request will be sent back a response to the client browser with this redirect URI.

In our case, we are mention Valid OAuth Redirect URIs as 

https://localhost:8443/FacebookApp/login

Now, Facebook required for HTTPS to Valid OAuth Redirect URI.

Finally, note down the Facebook Application App ID and App Secret from Basic Settings.

After creating a web application in Facebook, we develop the Client Application using MAVEN.

First, go to this GitHub link https://github.com/Sathveegan/FacebookApp_OAuth and clone or download the application.

Project Structure

After download the project, go to the FBConnection class and modify the APP ID and APP SECRET using your previously received APP ID and APP SECRET in above steps.

Then, go to the root folder and build the project using flowing command. Before building the project makes sure MAVEN is already installed or not. If not, go to the maven https://maven.apache.org/ page and download it.

After building the project, go to the target folder in our application and copy the FacebookApp.war file in somewhere.

Next, we will set up the Apache Tomcat server for deployment.

First, download the server from Apache Tomcat http://tomcat.apache.org/ page.

Normally, Tomcat runs in HTTP. But, we used HTTPS for redirect URI, So we set up the Tomcat Server to HTTPS.

Generate the KeyStore file for HTTPS using the following command.

Then, modify the server.xml file using the following command, which is in the conf folder in the root folder of Apache Tomcat.

Next, paste the FacebookApp.war file to the webapps folder in the root folder of Apache Tomcat.

Finally, run the Apache Tomcat using following command.

To run, go to the bin folder in the root folder of Apache Tomcat and type catalina run command in terminal.

Now we are deploying our application in Apache Tomcat Server.

Go to the https://localhost:8443/FacebookApp link and click the Continue with Facebook button on the web page.

If you click the Continue with Facebook button, page redirected to Facebook login page.

In the login page, enter your username and password then click the login button.

After login, user is redirected to User Consent Page of Facebook, which would require user consent showing what privileges will be given to the Application, what the application can do as the user, what resources of the user can be accessed by the Application, and you can specify which and which permissions will be granted to the Facebook Application.

After, click the Continue button in the User Consent Page.

Now, the page is redirected to our Facebook Application and also Contact Form of our application is filled using information which is coming from Facebook resources.

Finally, we are built, deployed and ran Facebook Application using “OAuth”.

Now, we look down the main source code of our client application.

Obtain Authorization Code from Facebook

When click the Continue with Facebook button in Contact Form, index.jsp call getFBAuthUrl() method in FBConnection class.

getFBAuthUrl() method used to create Authorization URL for getting Authorization Code from Authorization Server on Facebook. Authorization URL contains APP ID, redirect URI, response type and scope. Some fields are encoded using URLEncoder.

In LoginServlet class, get Authorization code which is redirected from Authorization server on Facebook.

Obtain Access Token from Facebook

After obtaining Authorization Code successfully, LoginServlet class call the getAccessToken() method with the authorization code as a parameter.

getAccessToken() is a method created for getting access token from Authorization Server on Facebook. It makes a request to access token endpoint with grant type, authorization code, redirect URI and APP ID. APP ID and APP Secret are encoded using Base64 and set as a header in above request. The response of the above request is retrieved and get the access token using JSON handling.

Retrieving User Resources from Facebook

After obtaining Access Token successfully, LoginServlet class create an object in FBResource class with access token as a parameter and call the getFBResource() method for getting the user resources. getResourceData() method used to map the retrieved user resources to HashMap.

getFBResource() method make a request to the Facebook graph API with access token as Authorization Header and obtain the user resources as JSON string.

getResourceData() method used to parse the JSON string data to HashMap with related key values.

Finally in LoginServlet class, mapped HashMap key values are retrieve by key, and set to request attribute using setAttribute() method for display the relevant user resource on web page.

In index.php, user resources values are set to contact form using getAttribute() request method.

In web.xml, web application related servlet and servlet mapping are defined.

Download the Source Code

GitHub Link: https://github.com/Sathveegan/FacebookApp_OAuth

Double Submit Cookies Pattern in CSRF Protection

This blog is to explain about an implementation of the “Double Submit Cookies” used to mitigate Cross Site Request Forgery (CSRF) attacks. The proposed application is a simple web application developed in PHP.

Cross Site Request Forgery (CSRF)

Cross Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

In the case of a CSRF attack, the browser is tricked into making unauthorized requests on the victim’s behalf, without the victim’s knowledge.

The general attack scenario contains the following steps:

• The victim connects to the vulnerable web site, so it has a real, authenticated session.
• The hacker forces the victim to navigate to another website containing the CSRF attack.
• When the victim's browser execute the website page, the browser will execute a request to the vulnerable website using the user authenticated session. The user is not aware at all of the fact that navigating on the website will trigger an action on the vulnerable website.

This attack could result in a transfer of funds, changing a password, or purchasing an item in the victim’s context.

In order to mitigate the CSRF attacks the following techniques can be used:

• Check standard headers to verify the request is same origin
• Determining the origin the request is coming from (source origin)
• Determining the origin the request is going to (target origin)
• Synchronizer Token Pattern
• Double Submit Cookies Pattern
• Encrypted Token Pattern
• Custom Header

Double Submit Cookies Pattern

The above diagram describes the Double Submit Cookies Pattern in the following steps:

1. Client browser request login page and log in to the system.
2. Server authenticate the client and generates the session id and CSRF token. CSRF token value is not stored in the server side.
3. generated session id and CSRF token value are set as cookies in the browser.
4. Client request the page to the server.
5. Server send the HTML of the requested page.
6. When HTML form is loaded, javascript reads the CSRF token cookie value in the browser and add a hidden field to the HTML form modifying the document object model (DOM).
7. Send the HTML form to the server.
8. Once the HTML form is submitted, in the server side, obtain the CSRF token received in the cookie and also in the message body, and compare the two values received.
9. If the compared CSRF token is match, show success message. If not show error message.

Let's Try Out Practically

You can clone or download the source code from the GitHub and run it on localhost.
GitHub link: https://github.com/Sathveegan/CSRF_Double_Submit_Cookies_Patterns

Or

Just click to access the demo from the following URL,
Demo Link: https://csrf-token-double-submit.herokuapp.com/
You can enter the username and password in this login form.
Username: sath Password: 12345678

If the login credentials are invalid, login page will show an error message.

When login, session identifier and CSRF token are generated and set as cookies in the browser.

CSRF token value is not stored in the server side.

After successful login, you will be redirected to the home page. In this home page contains the Contact Form.

When HTML form is loaded, javascript reads the CSRF token cookie value in the browser and add a hidden field to the HTML form modifying the document object model (DOM).

Inspect the page and see that there is a hidden field having the CSRF token value embedded on it.

Fill the Contact Form and submit.

As we have not modified anything there in the CSRF token field, the page redirected to the result page with success message.

In case attackers try Cross Site Request Forgery (CSRF) on our web page.

We are modifying the CSRF token value and submit the form to witness above scenario.

The page redirected to the result page with fail message saying that the attack is successfully eliminated using Double Submit Cookies Pattern.

Overall Project Structure

index.php

index.php is created for login page.

login.php

login.php is created for validate the user and generate the session identifier and csrf token to set as cookies in the browser.

home.php

home.php is created for display the Contact Form and reads the CSRF token cookie value in the browser and add a hidden field to the HTML form modifying the document object model (DOM) using javascript.

csrf_token_validator.php

csrf_token_validator.php obtain the CSRF token received in the cookie and also in the message body, and compare the two values received.

If the compared CSRF token is valid, return true. If not return false. 

result.php

if csrf_token_validator.php return result is true, result.php show success message. If not show fail message.

file.txt

file.txt is used to stored the session_id n the server side.

CSRF token value is not stored in the server side.

logout.php

logout.php is used to destroy the session of the user.

GitHub Link: https://github.com/Sathveegan/CSRF_Double_Submit_Cookies_Patterns

Demo Link: https://csrf-token-double-submit.herokuapp.com/