What is OAuth 2.0 ?
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to HTTP service, either on behalf of a resource owner by making an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own.
Evolution to OAuth 2.0
Nowadays, all mobile applications use web-services for various activities. With advanced reverse engineering, anyone can find your API details and can make malicious requests on your behalf. In order to prevent this, OAuth 1.0 was introduced. It required validation of client application for each request with predefined Username and Password. If a third party application needs to use our API, we have to share the Username and Password with them. This may create security breach and vulnerabilities into our system. As third-party application would need access to user credentials for future use, it will store the username and password in its system. That’s why OAuth 2.0 is widely used these days.
Vocabulary of OAuth 2.0
-
Resource Owner: An entity capable of granting access to a protected resource. Most of the time, it’s an end-user. In case of mobile application, it will be middle tier server.
-
Client: An application making protected resource requests on behalf of the resource owner and with its authorization. It can be a server-based, mobile (native) or a desktop application.
-
Resource Server: The server hosting the protected resources, capable of accepting and responding to protected resource access requests.
-
Authorization Server: The server issuing access grants/tokens to the client after successfully authenticating the resource owner and obtaining authorization.
-
Access Token: Access tokens are credentials presented by the client to the resource server to access protected resources. It’s normally a string consisting of a specific scope, lifetime and other access attributes and it may self-contain the authorization information in a verified mode.
-
Refresh Token: Although not mandated by the spec, access tokens ideally have an expiration time which can last anywhere from a few minutes to several hours. Once an access token has expired, the client can request the authorization server to issue a new access token using the refresh token issued by the authorization server for accessing protected resource.
Authorization with OAuth 2.0
As shown in below picture, client requests token for the first time and is provided with AccessToken, RefreshToken and expire time. After this expiry time passes user has to request new Access Token using this RefreshToken.
]Benefits of OAuth 2.0
Going by the adoption rate, OAuth 2.0 is definitely an improvement over its arcane predecessor. Instances of developer community faltering while implementing the signatures of 1.0 are not unknown. OAuth 2.0 also provides several new grant types, which can be used to support many use-cases like native applications, but the USP of this spec is its simplicity over the previous version.
PseudoCode for integrating OAuth 2.0 with Volley
//Check for Token Expired time if expired first refresh it
If ( current time > token expired time ) {
JsonObjectRequest jsonRequest = new JsonObjectRequest(com.android.volley.Request.Method.POST, “SERVER URL FOR REFRESHING Token”,”Your refresh Token”,
new Response.Listener<JSONObject>() {
@Override
public void onResponse(JSONObject response) {
// Store new authentication token and update expire Time
// continue if any request is ongoing
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {}
});
else{
//We have Right Authentication Token we can proceed
JsonObjectRequest jsonRequest = new JsonObjectRequest(com.android.volley.Request.Method.POST, “YOUR SERVER URL”,”Parameters if any”,
new Response.Listener<JSONObject>() {
@Override
public void onResponse(JSONObject response) {
//store auth token you have received and pass it in subsequent requests
})
{
@Override
public Map<String, String> getHeaders() throws AuthFailureError {
headers.put("Accept", "application/json");
headers.put("Authorization", "Bearer " + “Your Token”);
}
};
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
// check for error and retry
}
});
}
Note
Before making request always check for expiry time, whether it has passed or not, if not refresh your Access Token using current RefreshToken and resume your workflow with new access token.
