It is an way by which users can grant access to their information on the other website without sharing the password. OAuth is an standard which governs that how the application is going to fetch the information from the other website. There are few components which is being used in this these are:-
Authorization Server: This maybe an application such as Facebook, Google which originally have your information..
Client Application/Client Resource: Any application which want to fetch your information from the website which originally have it. (Fetching the information from the authorization server).
So let suppose while applying for a job on any company their website asks you to login or to fetch your information from the Google or Facebook now instead of creating the account on the website you choose to fetch the information from the facebook. You click on Login with Facebook button, the application opens up a popup windows and asks for your facebook credentials as soon as you provide the facebook credentials application asks you to authorize the job company so that it can fetch the information from the website. As soon as you click on the authorize facebook provides a secret access token to the job company which can use this to fetch your information from the Facebook.
Let’s look at the URL and the OAuth implementation of Login with Facebook on Udemy.
· Origin of Request/Application ID/ Client ID: Whenever request comes to Facebook, first thing it will check who made this request. Each and every website has to register on Facebook in order to use OAuth on Facebook. So this numeric id directly represents that app id on Facebook.
In above example you can see, both are same.
· Scope or information which needs to be shared:
a. After checking the scope from OAuth request, Authorization Server will check for how many resources end user wants to share from Authorization Server.
b. Client Application can request one or more than one scopes.
c. Generated access token will limit the scopes in Authorization Server like end user only have rights to fetch the information of the public profile which may include Name, Gender, and profile picture.
· Redirect URI: After the successful authorization from Authorization Server, Authorization Server will again redirect the end used to client application with the access token in the URL. So redirect URI contain sensitive information such as access token, and state parameter. The redirect URL can be set while creating the App on the authorization server.
After authorization from Facebook, Facebook will return to above mentioned URL.
· State parameter: State parameter is unique and must be unique with every OAuth request and it is used as a CSRF protection token to protect end user. So it eliminates the CSRF attack in the OAuth implementation.
Here we can see entropy of state parameter is high so no one can easily bruteforce or guess it.
OAuth 1.0 & OAuth 2.0: OAuth 1.0 is completely deprecated and now a day’s application are using OAuth 2.0 because it is faster and simple to understand and have more security features as compare to Oauth1.0.
To provide functionality to end user and remove the hassle which users face while creating the account and remembering the password on different website, applications uses OAuth. OAuth usually works with SSL so it is mostly safe from the MITM. The below diagram denotes how the OAuth works.
1. End-User wants to do login into any application.
2. Client application uses OAuth functionality user clicks on login with Facebook so the client application redirect the user towards Authorization server(Facebook) for Authorization. This request have multiple parameter such as redirect Uri, client id/ application id and scope which was defined earlier in this blog.
· Authorization server starts validating redirect Uri, to matches is this URL is one of them from registered URL or not?
a. If URL is not register: Authorization server immediately show an error stating Access Denied.
b. If URL is registered: Move to check which checks which permission are needed.
c. User provides his credentials and approve to share the data with client application.
3. After user clicks on the approve button authorization server redirects the user to the client application with an access token and the same state parameter application sent the request with
4. Client application verifies that the state parameter matches with on they have generated in the initial steps of this request
5. If this state parameter matches the user can login to the client application with the information fetched from facebook. Now further steps are required.
Consequences if OAuth not implement properly:
Here I am explaining some basic ways to exploit OAuth functionality.
· Insufficient redirect URI Validation: Some developer set redirect URI to top-level domain. They do not specify URL or perfect pattern match if a subdomain is available for takeover attacker can take that over and can steal the credentials of the user.
· State parameter: It includes some key points that I want to mentioned.
1. State parameter missing: As per specification state parameter is not a
necessary field so we can skip it may make the request vulnerable to CSRF attacks.
2. Entropy Of state parameter: If state parameter is set but entropy is very low. Attacker can bruteforce it. So it is possible for attacker to bypass CSRF attack which was due to the state parameter
3. Reused State: If state parameter is same in multiple request so there may be possibility that attacker can use it for future request to bypass the CSRF token.
4. State Validation: Sometime request can be accepted by server as attacker provide null value in state parameter field. So make sure state parameter must be accepted with valid and not with a nullified value.
· Open redirect in OAuth: After getting the token form authorization server. OAuth request will be redirected according redirect URL. If this redirect URL is not set at server side , attacker can modify it and in worst case scenario that token will be redirected towards malicious application.
· Always validate and set the redirect URL carefully because it may lead to the leak of access tokens.
· State parameter must generate a random string and entropy of that string should be high.
· Exact match of redirect URI should be necessary with pre-registered URI’s.