OAuth Security Overview

OAuth (Open Authorization) is an open standard protocol for authentication and authorization that enables the third-party application to obtain a limited access to an HTTP service.

In OAuth, “Auth” stands for Authorization as well as Authentication. Before OAuth, there were other authentication methods used to protect the user’s ID and password from other applications. When user accesses a secured web application it first verifies your identity by login us in and then it ensures that users have access only to data or functionality in the application which are authorized. So basic requirements are identity and permission for authentication and authorization.

OAuth allowed an application to gain access to users data within another application without knowing the user login ID and password for the second application. When authentication by OAuth is performed, the service provider asks whether a user wants to authorize the request of the third-party application or it has their own authentication.

OAuth History

Fig: OAuth History 

• Nov 2006: Blaine Cook begins working on OAuth while at Twitter, developing the Twitter OpenID implementation
• April 2007: Ma.gnolia, Google, and others join the discussion
• July 2007: Eran Hammer joins and soon leads the specification
• Dec 2007: OAuth 1.0 final draft
• November 2008: Google OAuth 1.0 support begins
• August 2010: Twitter forces all third party application to use OAuth 1.0, standardized through IETF
• June 2012: Eran ragequits the OAuth 2.0 body after the shift from crypto to bearer tokens
• October 2012: OAuth 2.0 framework and Bearer Token Usage published with 4 official grant type

OAuth 1.0 

OAuth v1 standard workflow 

Fig: OAuth v1 workflow

1. At first client/consumer need to sign up with the respective OAuth provider e.g. Google, Twitter, Facebook, to get client credentials. Usually a client key and secret.
2. In this step it obtains a request token from the service provider which identify client in further step. In this step it only need client key and secret from the service provider.
3. Now to access protected data/resources, obtain authorize from the user (resource owner). This is mostly done by redirecting the user to a specific URL to which user can add request token as a query parameter.
4. In the step it obtain an access token from the OAuth provider.  Save receive token might be reused later.
5. And finally get access to protected resources. OAuth1 access tokens typically do not expire automatically after use. Hence, reused until revoked by the user.

Vulnerability in OAuth 1.0

1. Locally stored secrets

Fig: OAuth v1 workflow

Above figure demonstrate the working flow of OAuth v1 with locally stored secrets vulnerability.

Vulnerability impacts: 

• Malicious application can impersonate a benign application.
• Break authorization.

Mitigation:

• Do not store any secrets into the client application.

After patching this vulnerability it updated to version OAuth v1a, but OAuth v1a is vulnerable with Evil URL Redirect.

2. Locally stored secrets with evil URL Redirect in OAuth v1a

OAuth v1a mitigate the vulnerability in OAuth v1 but it not completely mitigating the vulnerability from the core because after mitigating vulnerability it  leads to another vulnerability known as Evil URL redirect. So, for this OAuth v1a uses the verifier to secure the OAuth v1 flow.

An OAuth 1a verifier is nothing but a verification code tied with request token. Both the OAuth verifier and request token must be provided in exchange for an access token with the respective service provider and replying party.

Fig: OAuth v1a workflow

• Victim user goes through login process at client end using service provider site for authorization.
• Attacker modifies an authorization request URL for provider site to the malicious request.
• Attacker either embedded customized evil URL in any form to create a clickable link at the client side.
• When Evil malicious URL loaded, the service provider will 302 redirects back to redirect_url.
• When redirect happens, an evil site can read the http referrer to get the authorization code.
• Using this authorization code, Attacker can login as user

Mitigation:

• Service Provider should register the redirect URL and validate redirect URL
• Used whitelisted URL for redirect
• Replying party should not bundle the request of client secrets into the mobile application

OAuth 2.0 

The OAuth 2.0 authorization framework which 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.  This specification replaces and obsoletes the OAuth 1.0 protocol. OAuth 2.0 is not compatible with OAuth 1.0 

OAuth v2.0 standard workflow 

Fig: OAuth v2.0 workflow

OAuth V2.0 has 4 official grant type as mention below:

1. Authorization Code Grant (Web Application Flow).
2. Implicit Grant (Mobile Application flow).
3. Resource Owner Password Credentials Grant (Legacy Application flow).
4. Client Credentials Grant (Backend Application flow).

Among this 4 grant type, Authorization code grant and Implicit grant use in the real world.

Vulnerability in OAuth v1a is mitigated with intent URL that registers by the replying party application.

An Intent in the Android is a mechanism that allows users to interact with the functions of different application activities to achieve a respective task.

Fig: OAuth 2.0 implicit flow – Handling redirection

 Vulnerability in OAuth 2.0

1. Overwriting URL Redirect in mobile application

URL redirection use by web application and server to submit a user defined secured link for redirection to the respective page to access functionality even though it seems harmful action which can lead to the phishing attack.

Fig: Overwriting redirect URL

In this type of vulnerability, the attacker can register and overwrite the callback for the intent scheme in the android.

Vulnerability impacts:

• Attacker can access user’s service provider data with consent.

Mitigation:

• Secure redirect using android intent
• Each android application is securely signed using developer key
• Verify the hash value of developer key of the intent receiver.

2. Using OAuth 2.0 implicit flow for authentication

Authentication is nothing but a process for the user to prove identity by supplied credentials to a replying party, through which existing session with the service provider can utilize. The insecure authentication process can break authorization, which leads to Privilege escalation vulnerability.

Fig: Authentication flow in OAuth 2.0

Above figure demonstrate the implicit flow in OAuth 2.0 for authentication which is not secure.

• Replying party will send client_id, redirect_url, redirect user to gain access to the service provider
• Service provider generate the access token and redirect user back to replying party
• Replying party will send access token to service provider which is not bound to replying party. Hence it’s vulnerable
• Finally, the service provider will share user_id to replying party

Vulnerability impact:

• Full account compromise vulnerability

Mitigation:

• Enforce 2-factor authentication
• Adopt OpenID for secure authentication
• Service provider has to verify that the authorization code belongs to the respective replying party with proper authorization.

3. Service provider not verifying authorization code 

Authorization is a process that comes after successful authentication by which a server determines that user has permission to access a secured resources. There must be secure authorization procedures that enforce what type of application/resource user can access, for this ensure adequate authorization checks for the user according to security policy.

Fig: Authorization flow in OAuth 2.0

Vulnerability impact:

• Full account compromise

Mitigation:

• Service provider should verify the receiver and sender of security critical content such as code and token
• Replying party should cross verify on the server side.

4. Not using session token vulnerability

To protect the security of logged in users by preventing request forgery attacks, the client application should use state token. For this firstly create a unique session token that holds user state between application and server. After creating unique session later match this created unique session token between user and server with the authentication response returned by the authorization server to verify that the user is making the genuine request, and it’s not a malicious attacker. These type of tokens are often referred to as CSRF tokens. It maintains OAuth session integrity.

Fig: No Session Token

Replying part should use state token to identify the login session.

For example: Below secured version link uses the state token for reference.

https://www.xyz.com/uas/oauth2/authorization?response_type=code&client_id=75h1uwzb0nu99r&redirect_uri=https://www.website.com/_oauth/linkedin?close&scope=r_emailaddress+r_basicprofile&state=eyJsb2dpblN0eWxlIjoicG9wdXAiLCJjcmVkZW50aWFsVG9rZW4iOiJ2MlVpQ3lrNkhUb2J1S0pMUGU4bmJvWDVZZnl6YzJsUk0tZ3BGV2xxd093IiwiaXNDb3Jkb3ZhIjpmYWxzZX0=

Mitigation:

• Service provider should support state token
• Replying party have to verify state token when getting back from service provider

5. WebView Vulnerability

A WebView is nothing but an android UI component that displays webpages for the user. It can either display a remote webpage or static HTML page. It provides interesting methods for pages to interact with the Android application using the JavaScript. Due to this functionality in WebView it must be implemented securely.

• Vulnerability such as Cookie in WebView: This type of vulnerability exists because service provider set long duration cookie in the WebView which allows attacker to log into the user’s account.

• WebView allows to load plain-text content.

• If WebView functionality is allowing the user to access content from other applications that exist in the similar device then it possible for an attacker to create a customized malicious HTML request to inject inside the target application. For this, it must have proper application permission.

Mitigation:

WebView functionality can expose the application functionality and the device secrets which leads to security risk. So, while implementing WebView following function much be implemented securely.

• Set allow Content Access
• Set JavaScript Enabled
• Set Allow UniversalAccess From FileURLs
• Set Allow FileAccess From FileURL
• Set Allow File Access

How to use OAuth securely:

Service Provider 

• Verify the identity of token/Code receiver
• Informative content page
• Adopt OpenID connect for authentication.

 Replying party 

• Do not trust client
• Do not store content locally
• Perform security check on the server

 Reference:

• https://tools.ietf.org/

• https://www.owasp.org/

• http://docs.spring.io/spring-social/docs/1.0.0.RC1/reference/html/serviceprovider.html