OAuth Security Implementations For Web Applications

The OAuth (Open Authorization) protocol is a standard for delegating web access between websites without requiring the user to type their password. It is a way of granting permission to use a user’s account from another provider to gain access to a website. It is used by many companies that provide a service on the Internet (e.g. Facebook, Twitter, Netflix). Although it is a more convenient way for users to access websites since it doesn’t require typing a password, it can also be exploited. It can be used as an attack vector to compromise a user’s account or even to gain illegal access to a website.

Brief Overview

There are different websites that offer a variety of services. When we access e-mail, blogs, cloud apps and streaming services we use our personal user account. This was created during the sign-up process. We provide a username and password, then our account is created. We use this account every time we want to access that service.

Some websites use OAuth to allow delegated access from a trusted website. For example, if you have an existing Google account, a certain website can allow you to access their website without creating a new account with a different username and password. Instead you use delegated authorization in which you are granted permission to use a website’s service from a trusted website. The web servers use public key cryptography with digital certificates (SSL/TLS) to authenticate each other to allow OAuth.

The servers between Google and the website have an understanding by way of the OAuth protocol. Since they have a trust relationship, all a user needs is to provide their Google account to gain access to the trusting website (Google is the trusted website that authenticates the user). It may still require the user to sign in if they are not at that moment, so they just need to provide their Google account password. These credentials are then passed to the web server. Once it has been entered, the web browser can remember it so the next time the user visits the website they don’t have to repeat that process all over. The level of access or privilege a user has on the trusting website can be limited, depending on the security policy implemented.

Architecture

While this works well for users, it can be exploited by bad actors. The tradeoff for convenience can be less security. It was originally developed as a way to share access to data between different applications across the Internet. The system architecture requires 3 elements:

• OAuth Provider
• Client Application
• Resource Owner

The OAuth Provider is the website or application that provides control and access to user data. An API is used for interacting with the authorization server and with a resource server. The OAuth Provider is the trusted website.

The Resource Owner is the trusting website. This is the website a user wants to access that contains the specific data. By authorizing access to the OAuth Provider, the user will have access to the Resource Owner which stores the information or provides the service that is needed.

The Client Application is just the UI that is accessed by the user, either through a web browser (more common) or a terminal application in some cases (e.g. Citrix). This is how the user interacts with the data or service, while at the backend you have the Resource Owner providing the data or service which has been authorized by the OAuth Provider.

Exploits

Since the OAuth protocol is flexible by design, it can also introduce vulnerabilities that can be exploited. An example get authorization request can be in the form:

GET /v1/projects/abc/databases/123/indexes HTTP/1.1
Authorization: Bearer SIGNED_JWT
Host: firestore.googleapis.com

Vulnerabilities can arise in both the Client Application and OAuth Service. This can happen if the developer is using redacted code from an older OAuth library. It is best practice to the use most stable and secure version (refer to OAuth.net for the latest framework). The main exploit that can be used against OAuth are authorization vulnerabilities.

On the Client Application, an implementation of OAuth could be insecure when using the implicit grant type. As the name suggests, a trusting website can implicitly allow access if it has no secret or password to compare with the submitted data from the client. The Resource Owner should verify that there is a token sent from the Client Application that authorizes their access. Let us say that we have the following token generated:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJqbGVlIiwic2NvcGVzIjpbIlJPTEVfQURNSU4iXSwiaWF0IjoxNjEyNDE3MDQ1LCJleHAiOjE2NDM5NTMwNDV9.Awy3bH4xJYU7neMVW5yFc4WabBSBW7I8FfF8Xgf0cuY

The token’s validity is checked by the Resource Owner. The Client Application should then forward its credentials:

{
  "username":"johnsmith",
  "email":"johnsmith@domain.net",
  …
}

If the token and credentials are valid, the Client Application is granted an authenticated session and access to the data or service.

Another exploit is the flawed CSRF protection. This is through the absence or lack of the state parameter. The state is supposed to contain a value that is hard to guess like a hash value. It is generated by the server-side application and should not be predictable. It is then passed between the Client Application and the OAuth Service as a CSRF Token. If a website allows users to log in using a password-based mechanism or linked account to a social media profile using OAuth, there should be a state parameter set. If there is none, an attacker could hijack a user's account.

On the OAuth Service side, a serious exploit can be the unauthorized access to leaked security codes and access tokens. If I were to steal the access token from the previous example and know the credentials of the user, it can be used to gain access to the Resource Owner, That would effectively allow the hacker to access a user’s personal data and to use the services available.

Then there is a flawed scope validation. In OAuth, the user must first approve the access request based on the authorization request. A hacker can elevate the scope using nefarious means like a stolen access token that contains extra permissions outside of the original grant type for the user. This can happen if the OAuth Service is not properly configured.

Finally, another exploit that is a critical concern is unverified user registration. This can arise because the Client Application assumes that the information the OAuth Service has is correct. The hacker can exploit this by using the same information as the user to access the Resource Owner. This can be as simple as obtaining the username and e-mail address, for example, and pass those on to the OAuth Service to be granted access.

Synopsis

While it is ideal to implement for ease of use and convenience to users, there are certain things that should not be overlooked when implementing the OAuth protocol. Implement best practice always and not the simplest method. If a user’s credentials to gain access to a trusting website is just an e-mail address, this is very insecure and should be changed immediately. The use of security access tokens and certificate validation on the backend can help tremendously.

Disclaimer: This is for information purposes only. Hacking and other cybersecurity attacks are punishable by jurisdiction and not encouraged.