Securing RESTful APIs using OAuth

What is OAuth

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a 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

 OAuth Roles

OAuth defines four roles:

• resource owner:

Could be you. An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

• resource server:

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

• client:

An application making protected resource requests on behalf of the resource owner and with its authorization. It could be a mobile app asking your permission to access your Facebook feeds, a REST client trying to access REST API, a web site [Stackoverflow e.g.] providing an alternative login option using Facebook account.

• authorization server:

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

OAuth Authorization Grant types

An authorization grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token. The specification defines four grant types:

• authorization code
• implicit
• resource owner password credentials
• client crederce owner password credentials grant type. 

1.Resource Server

2.Authorization Server

3.REST API

Sending Request to /oauth/token with grant_password and resource owners credentials will generate the access token and refresh tokens

http://localhost:8080/Securing_RESTful_API_with_OAuth/oauth/token?grant_type=password&username=User1&password=abc123

Use the token you received to access the resources 

GET http://localhost:8080/Securing_RESTful_API_with_OAuth/user/?access_token=3525d0e4-d881-49e7-9f91-bcfd18259109

CSRF Synchronizer Token

CSRF

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.
CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password, or purchasing something. Forcing the victim to retrieve data doesn't benefit an attacker because the attacker doesn't receive the response, the victim does. As such, CSRF attacks target state-changing requests.

Synchronizer Token as a Protection

Synchronizer tokens are often referred to as “challenge” tokens. These challenge tokens are included within an HTML form and associated with sensitive server-side tasks. When a user wants to execute a sensitive operation the request needs to include the challenge token.
On the server side, the web application verifies that the request includes the token. If it does not, the server rejects the request. Note that this method does require a server side state to be stored and quickly accessible. It is currently considered the best way to prevent CSRF attacks.

Code for the Synchronizer Token Example is found Here

image via : Stormpath.com

image via : Stormpath.com

CSRF Double Submit Cookie

What is CSRF?

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Double Submit Cookie as a protection

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.
When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.

Vulnerable app and the protection can be downloaded from here.