OAuth Is Convenient, But Is It Secure?


Earlier this year, a phishing attack targeting Google Docs abused OAuth to give hackers full access to victims’ Gmail accounts and contacts. Google blocked the attack within about an hour, but it might have affected as many as a million Gmail users.

Here’s how it worked. The attackers got access to Google’s OAuth APIs by posing as legitimate third-party application providers. They sent victims phishing emails containing a link to what appeared to be a Google Doc. The link sent victims to a Google account selection screen and asked them to grant access to Gmail messages and contacts. The malicious code continued to spread by sending itself to everyone in the victims’ contact lists.

The attack appears to have been more mischievous than malicious, and Google quickly contained it by disabling the hackers’ accounts and revoking their access to any compromised accounts. Google also said it would change its policies regarding the use of OAuth APIs by third parties. Nevertheless, such an incident could have been devastating to enterprises that use Google Docs to store sensitive data. It points to the risks associated with insecure OAuth implementations.

OAuth is an open-standard specification for allowing users to share account information with a third party without revealing their passwords. First introduced in 2007 as a means of providing access to Twitter accounts, it is now commonly used to link a wide range of web-based, mobile, and desktop applications. If you wanted to import your Gmail contacts into LinkedIn, for example, you’d give LinkedIn access to your Gmail account via OAuth. OAuth also allows you to log in to third-party apps using your Google or Facebook account. For the purposes of this article, we will henceforth use Google as shorthand for any identity provider.

When a third-party app wants to access your Google account, it first has to get your permission. The app packages a request for authorization, then typically pops up a window telling you what the app plans to do and asking you to allow or deny access. If you click “Allow,” you will be redirected to Google, where your account will be authenticated, if necessary, and the authorization request will be processed. If Google is satisfied that you are who you say you are, an authorization token will be sent back to the app. With the token, the app can access your Google account and do what you’ve authorized.

Several security risks are associated with OAuth. Here are three examples:

  • Google has no way of knowing what app is requesting authorization. An attacker could use a legitimate redirect link and hijack the authorization token.
  • OAuth does not include a mechanism for authenticating the server that users are redirected to. Users could be sent to a site that contains malicious content or tricks them into entering their Google account information.
  • In many cases, the authenticated Google session remains open after the user is redirected back to the third-party app. The user might not think to go back and log out of Google.

Combating these threats requires a combination of user awareness and improved application development. Users should receive training to help them spot phishing attacks and malicious redirect links. Application developers should do a better job of following OAuth implementation guidelines, performing checks and validations, and testing code for security.

OAuth has proven to be a convenient means of sharing data among applications. However, as the Google Docs attack shows, organizations should take steps to ensure that convenience does not bring compromised security.


For more information about OAuth implementations and training, please send us an email at (

Leave a Comment