Get To Know OAuth

If you try to create an account or login to some websites or any other application, as an example when you want to create an account in NVIDIA, there’s an option that you can create an account simply by using facebook.



So there’s this button called “Login with Facebook” which you click and use your facebook account’s details. It’s easy to use facebook than creating a new account and remembering the passwords and all, and your facebook account also holds the relevant information. Did you ever think about what’s happening behind the scene of this process? That’s where the OAuth comes in.

OAuth is an authorization framework that enables a third-party application to obtain limited access and use authorized resources of a HTTP service, as an example facebook. This can happen either on behalf of a resource owner by arranging 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. 
(At the time I’m writing this blog, OAuth 2.0 authorization framework is used)

How this works?

Before we go further in to details, lets identify the main roles when it comes to the OAuth 2.0 framework.

OAuth defines four roles,

  • Resource owner 
We can simply call this one as the user, the entity using the third-party application or the entity capable of giving access to the protected resources. And if the resource owner is a person, he or she can be called as the “end-user”.
  • Resource server
The server that keeping the resource owner’s protected resources. And this server is capable of accepting and responding to protected resource requests using access tokens.
  • Client
This is the third-party application that making requests on behalf of the resource owner and with its authorization. The client can be executes on a server, a desktop computer, a mobile phone, a laptop or any other device. 
  • Authorization server 
This is the server issuing access tokens to the clients after successfully authenticating the resource owner and obtaining authorization.


A simple example for you to understand the roles in OAuth 2.0 
(I used hypothetical users and server names for demonstration purpose)
Assume that there is a web based application called “SampleOAuth” that need user’s user name and e-mail address to create an account in its local database. It also has a special feature which users can simply create accounts by login with their social media accounts. Facebook is also a social media that this application allows users when it comes to creating accounts.

A user called “Kali” is now trying to create an account in this application and he use his facebook account to login and create an account in this application.

Facebook has a special server that issues access tokens and all, lets called this server as “The Facebook Auth server”

The roles of this scenario, 

  1. Resource owner is the user "Kali".
  2. Resource server is Facebook.
  3. Client is the "SampleOAuth" application.
  4. Authorization server is the "The Facebook Auth server".
In addition to that user’s (according to this example “Kali’s”) name and e-mail are the resources of this scenario. 


In traditional client-server authorization process, the client (the third party application) request an access restricted resource from the server by authenticating using the resource-owner’s credentials, as an example, client uses resource-owner’s username and password to get resource-owner’s birth date. Now this causes big problems and limitations. As some examples, 
  • The clients are required to store the resource owner’s credentials for future use, typically a password in plain text (readable /clear text) which is obviously not a good practice.
  • Third-party applications gain access to all protected resources of the resource owner.

OAuth solves this issues by introducing an additional authorization layer and separating the role of client from resource owner. In OAuth, the client (third-party application) requests access to resources controlled by resource owner and hosted by (stores in) resource server, and to get those resources client is issued a different set of credentials than those of the resource owner.

Instead of using resource owner’s credentials to access protected resources, client obtain an access-token, a string representing specific scope, lifetime, and other access attributes. Those access tokens are issued by authorization servers to clients (third-party applications) with the approval of the resource owner. In this process there is another validation for the access-token between resource server and the authorization server.


A simple diagram to demonstrate the flow. 





     +--------+                               +---------------+

     |        |--(A)- Authorization Request ->|   Resource    |

     |        |                               |     Owner     |

     |        |<-(B)-- Authorization Grant ---|               |

     |        |                               +---------------+

     |        |

     |        |                               +---------------+

     |        |--(C)-- Authorization Grant -->| Authorization |

     | Client |                               |     Server    |

     |        |<-(D)----- Access Token -------|               |

     |        |                               +---------------+

     |        |

     |        |                               +---------------+

     |        |--(E)----- Access Token ------>|    Resource   |

     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+


(A) The client requests authorization from the resource owner to access protected resources. This can done by directly with client and resource owner or via authorization server. If this is happening via authorization server, client need to send a request to the authorization server’s authorization endpoint. It depends on the grant type, whether we need an intermediate between client and resource owner or not. 
  
(B) The client receive an authorization grant from resource owner, which is a representation of resource owner’s authorization.

(C) The client request an access token from the authorization server by presenting the authorization grant received from the resource owner. This is done by sending a request to the authorization server’s token endpoint.

(D) The authorization server validate and authorize the authorization grant, and if and only if it’s a valid authorization grant by the resource owner, the authorization server issues an access-token.
   
(E) The client request protected resources from the resource server by presenting the access-token.

(F) The resource server validates the access token, and if and only if it’s a valid access-token, resource server serves the request.

So whenever you click on a “Login with facebook” or any other login with something, this process will happen behind the scene.

Retrieving access-token

This topic is an additional one that I need to share with you. However I’m planning to write a separate blog regarding OAuth 2.0 access-token grant types. But in this blog post I’ll give a basic idea about OAuth 2.0 access-token grant types.

When it comes to retrieving an access-token, in OAuth 2.0 framework it defines four access toke grant types,

1.      Authorization code

The authorization code is obtained by using an authorization server as an intermediary between the client and the resource owner.


2.      Implicit

The implicit grant type is a simplified authorization code. In this grant type, instead of issuing the client an authorization code, the client is issued an access token directly. There are no intermediate server.


3.      Resource owner password credential

The resource owner’s credentials (username, password etc.) can be used directly as an authorization grant to obtain an access-token. To use this grant type, there must be a good trust between resource owner and the client. As an example we can take the Facebook mobile application.


4.      Client credential

This grant type can be used as an authorization grant when the protected resources are under the control of the client. This grant type is used typically when the client is acting as the resource owner.



For demonstration, I developed a simple web based application using OAuth 2.0 Authorization Code grant type and Facebook graph API. You can view the source code using the following link. 

OAuthSample App With Facebook  

If you need to test this application on your own, read the README file and follow the instruction.  


Comments

Post a Comment

Popular posts from this blog

RMI (intro)

Image
What is RMI?  RMI stands for Remote Method Invocation. It is an application programming interface (API) that allows an object running on one Java Virtual  Machine (JVM) to invoke methods on an object running on another Java Virtual Machine (JVM), client server architecture is a good example where RMI is used. Basically, RMI provides for communication between programs written in the Java programming language. Architecture  In an RMI application there are two programs, a server side program and a client side program. Inside the server side program, a remote object is created and reference of that object is made available for clients. The client side program requests the remote object from the server to invoke its methods.  (A diagram to represent RMI architecture) Stub & Skeleton? Stub is a representation the remote object in the client and its acts as a gateway for the client program. Skeleton is the object that in the server-side. stub communicates with
Read more

Let's Configure HTTP'Secure' in Apache-Tomcat

Image
What is HTTPS?.. if you don't have any idea about what is HTTPS, refer my previous blog post about HTTPS . If you have an idea about HTTPS and SSL/TLS handshake, you are good to go 😊  Creating a digital  certificate We can create a digital certificate using "Java KeyStore (JKS)". This is a repository of security certificates. We can generate a keystore file using keytool command. in order to work with keytool, you must have "JAVA" installed in your computer.  keytool is a key and certificate management utility that allows users to administrate their own public/private key pairs, and the keystore file we are going to generate bellow will also be our local tomcat server's server certificate.   Options  When creating a "keystore", we need to provide some options and values to it. -genkey/-genkeypair -alias  -keyalg  -keystore  -keysize -validity -sigalg -storepass -keypass -dname  -genkey/-genkeypair -genkey
Read more

Mitigate CSRF with Double Submit Cookies

Image
I previously explained what is CSRF  and how we can mitigate a CSRF attack using Synchronizer token pattern technique. In this blog post I'm going to talk about another CSRF mitigation technique called "Double Submit Cookies Pattern"  😉 What is Double Submit Cookies Pattern? This is a technique, that sends a random seed or a "token" as we call it, in both a cookie and as a request parameter, with the server verifying if the cookie value and the request value match. Why DSCP? Now its obvious that a third party entity cannot perform a CSRF attack without the CSRF token, and in here attacker or the third party entity cannot get the token because its in a cookie, and third party web pages cannot retrieve cookies from another web page that has a different domain. For example, assume that the genuine web page is banker.com, and the attacker's web page is attacker.com, when a user logged in to the banker.com, and accidentally redirect to attacker
Read more