OAuth (Open Authorization) is a protocol that allows a user to grant a third-party application access to their data without sharing their account password. It allows users to authenticate and authorize third-party apps to access their data and resources stored on a given server— such as their account information, photos, and documents—without revealing their login credentials. OAuth is also used for one-click logins, allowing users to identify themselves to a web service without having to enter their username and password every time.
When one web-based service connects with another, the services work with the OAuth protocol to ensure safe interaction that doesn’t ask users to share passwords.
History
Sharing passwords is never recommended for any application. So large tech companies such as Google and Twitter introduced a solution named OAuth.
Back in 2010, Google offered a way for smaller app publishers to write services that used Google account information instead of requiring users to share their Google passwords with a third party. Instead of storing sensitive password data and maintaining security for user accounts, a third party could use Google’s system to ask users to authenticate and store an access token. The access token stored Google account authorization, and the third-party application then uses the OAuth token to access a defined set of Google account data.
The OAuth protocol has been through several iterations, with the last major improvements in 2012. Several other large tech firms now offer OAuth integration for third-party developers. Amazon, Netflix, PayPal, Microsoft, LinkedIn, Facebook, and many others allow third-party developers to integrate their user account data into apps using OAuth.
Why Is OAuth Used?
Before OAuth, every web-based service had separate credentials for a user account. Services could not share data unless they offered an API where data could be passed between the two. Even with an API, passing passwords across services is a security vulnerability, exposing private data across multiple services if just one is breached.
OAuth lets users give third-party apps access to their accounts for a wide range of features. Examples include using calendar data for easier scheduling, storing app settings in the cloud or even analyzing their music playlists for new recommendations. Passwords are no longer necessary for authorization, and users can revoke access at any time. Third-party app developers store an access token to retrieve authorized data, which must be securely stored but doesn’t expose user credentials.
How Does OAuth Work?
Three entities are involved with a successful OAuth transaction:
- The user (the person or organization authorizing access to their data)
- The OAuth service provider (is the app or service that stores the user’s data and credentials)
- The consumer (the application requesting access to the user’s data)
OAuth uses a defined workflow to ensure the security of user data and simplify requests for the consumer. First, the application requesting access (consumer) requests an OAuth access token from the service provider. If not already logged in to the service provider, users are asked to do so. The service provider then lists what kinds of data the consumer app seeks to access and asks the user to approve or deny access. If the user agrees, the service provider then sends an access token to the consumer, which stores it for future access requests. Once validated, the access token is used in all access requests for the user’s data (within the scope of the permissions granted by the user).
Access tokens expire, so service providers give developers a way to refresh access tokens for future requests. The timeframe for an access token is set by the service provider, so the duration depends on the service provider’s security protocols. The access token must be securely stored because it can be used by anyone to obtain user data and perform functions on behalf of the user.
Should users decide to revoke access, they can do so through the service provider. After access is revoked, the consumer must ask the user to re-authenticate to obtain any data stored on the service provider’s application. If the consumer suffers from a data breach where access tokens are disclosed, the service provider might proactively invalidate all access tokens to protect user data.
OAuth vs. OpenID
When consumers use OAuth, the service provider provides authorized access to a user’s data only after a user consents. OAuth is a way to share data using an authorization token provided by the consumer after the user verifies their credentials. OpenID is distinct from OAuth, but the two are used together.
Single sign-on (SSO) is a common security strategy that uses one provider to authenticate users into multiple services. OpenID is one of the oldest SSO protocols, introduced in 2005 to authenticate into LiveJournal. It’s been through some updates, but it was considered too difficult to implement compared to other methods at the time, mainly Facebook Connect. Because Facebook was a well-known brand, most developers switched to Facebook Connect to make users feel more comfortable authenticating into their apps.
In 2014, OpenID redesigned its code and was later incorporated into OAuth. Now, OAuth uses OpenID as its authentication layer, and OAuth deals with the authorization layer. The process is seamless to the user, but consumers can more easily integrate OAuth to both authenticate users and get access to their account data.
OAuth vs. SAML
An older product similar to OAuth is the XML-based Security Assertion Markup Language. The main difference between SAML and OAuth is that SAML performs both authentication and authorization. OAuth uses OpenID as an authentication layer, but it does not handle authentication on its own. Apps using SAML don’t need any other services to provide authentication.
Another difference between the two protocols is the language used to pass data between services. SAML uses XML; OAuth uses JSON, the preferred format for data transfers. Most data services work chiefly with JSON, making OAuth easier to integrate for most companies.
OAuth 1.0 vs. OAuth 2.0
Just like any other protocol, OAuth has evolved and improved over time. OAuth 2.0 has superseded OAuth 1.0 (which is no longer secure), so most service providers allow only OAuth 2.0 for access. OAuth 1.0 is easier to use and features a workflow that is simpler in some ways. But it’s no longer considered a secure way to work with user accounts.
OAuth 2.0 added two steps to the authorization workflow. It allows for HTTPS and signed secrets, so tokens no longer need to be encrypted on endpoints (user devices). HTTPS encrypts access tokens in transit, though some services that store personally identifiable information (PII) or other sensitive data still encrypt data at rest. One criticism of OAuth 2.0 is that it allows data transfers over unencrypted channels, so developers are responsible for maintaining TLS/SSL encryption across channels.
Examples of OAuth 2.0
For a developer to take advantage of OAuth 2.0, the service provider must have it implemented on their system. Several large social media sites use OAuth 2.0 to incorporate integration of their platform with other apps. It’s a marketing advantage that helps platform owners build a following for their products.
Since Google first released OAuth 2.0, many apps work with it as an SSO provider and a service that provides basic user information. In a simple OAuth 2.0 workflow, the consumer offers a link to “Log in with Google” as an option to create an account. If the user is already authenticated, Google displays a list of resources and data the consumer would have access if the user agrees.
The user can allow or deny the consumer’s authorization request. If the user declines, the consumer cannot access the user’s data. If the user allows the data request, the service provider gives the consumer an access token. The access token provides authorization only for the data listed in the original request. For most major platforms, a consumer app must be pre-verified by service provider before accessing certain data. Typically, the consumer outlines what data it needs to function and how that data will be used. The service provider can preemptively allow or decline the request.
OAuth is also used to integrate a platform into another service. Suppose that you had an app that worked directly with the Google product such as Gmail. To directly read your users’ emails, you need permission from the user. Google uses OAuth to allow your app to interact with the user’s Gmail account. To use the Google Gmail service in your app, you specify the data needed for the app to function; users must then authorize the app to access it.
Is OAuth Safe?
OAuth is safe if deployed correctly. The service provider must ensure that the consumer has authorization to data; the consumer must use TLS/SSL to make a secure connection and transfer data in an encrypted form. The service provider can ensure that data is transmitted securely by requiring consumers to use encrypted connections and rejecting any unencrypted channels.
OAuth Risks
While safer than sharing credentials, OAuth isn’t risk-free. Here are a few security pitfalls organizations should watch out for when allowing users to connect outside apps to their accounts using OAuth.
Phishing
The threat of phishing is a major concern with OAuth. Attackers often use links to web pages with requests for users to enter credentials to authenticate into their accounts. The page looks like an official page similar to a service using OAuth. But instead of authenticating into an official service, users is inputting their credentials to an attacker’s phishing website. Users should check the address listed in the authentication browser popup to make sure the site is legitimate.
In a phishing campaign we discovered, attackers gained access to Microsoft user credentials by modifying URL query string parameters to redirect users to credential-stealing website.
The phishing page displayed a spoofed Microsoft permission message that seemed familiar to most users. The page prompts users to log into their Microsoft account—but instead of authenticating users, it gives attackers the Microsoft account login credentials. These credentials can be used to take over Microsoft accounts, obtain user data or hijacks accounts on separate services where users reused those credentials.
Overly Broad Permissions
When users install and authorize apps through OAuth, they often click “accept” without closely reviewing the scope of permissions. Any app that has broad access permissions is a potential security risk to your organization.
Third-party apps can easily be exploited. Attackers can use OAuth access to compromise and hijack cloud accounts. Until the OAuth token is explicitly revoked, the attacker has persistent access to the user’s account and data—even if the user changes the cloud account’s password or uses two-factor authentication (2FA).
Our research found that many OAuth apps for Office 365 have high levels of permissions. Here’s a sampling of our findings:
- 30% of tenants have apps such as MailMerge365 with “Send mail on behalf of others” permission.
- 30% of tenants have apps such as TypeApp with “Manage Exchange configuration” permission.
- 70% of tenants have on average nine apps that use “Send mail as a user” permission (such as Task in A Box).
- Microsoft 365 tenants on average had 34 apps using “Access user’s data anytime” permission (as is the case with OneSync).
- Google Workspace tenants with third-party apps in the “games” category have 10 games on average.
Malicious OAuth Apps
Some apps and their OAuth permission requests are overtly malicious. For example, our researchers have been tracking an attack campaign named OiVaVoii that publishes malicious apps under the guise of trusted app publishers. Here’s how it works:
- The attacker first hijacks the legitimate app publisher’s account.
- Posing as the trusted publisher, the attacker then creates a malicious app and sends authorization requests to users, many of them high-level executives, via email.
- Unsuspecting users authorize the app, believing it came from the trusted publisher.
- With OAuth permissions granted, the attacker takes control of the user’s account.
In this campaign, we have detected takeovers of accounts belonging to CEOs, general managers, former board members and presidents. Typically, the takeover is the result of malicious OAuth apps stealing OAuth tokens or credentials.
The seemingly benign identity of the publishing organization was a substantial advantage, luring several unsuspecting victims to authorize the malicious apps. They mostly involved mailbox access (read and write), which allowed them to:
- Send internal and external malicious email
- Steal valuable information
- Create mailbox rules to send data to the attacker and continue getting users’ email after the attack
Figure 1: Screenshot of malicious app’s OAuth permission request.
Abuse of Legitimate OAuth Apps
Contactually is a legitimate cloud app that helps real estate professionals manage customers and sales. But in the wrong hands, its powerful features enable attackers to easily move laterally within a victim’s environment and maintain access.
We detected a campaign that started with email-based phishing to compromise users within targeted organizations. Using the compromised accounts, attackers authorized the Contactually app and set up mailbox rules that redirected or deleted email. The rules were likely designed to forward valuable mail to external accounts and delete evidence of the attack.
Contactually is a legitimate publisher. The app does have some broad app permission scopes, such as full access to user contacts and read/write access to their email. But these are similar to those used by any email client and well within the bounds of the app’s advertised functions.
Still, if attackers have compromised the account and authorize the app within your environment—as they did in the campaign we detected—they can exploit those functions to cause lasting harm.
OAuth Security Concerns: Abuse & How to Govern
OAuth apps integrate with cloud services adding valuable enhancements - and unwanted security risks. Learn the OAuth security concerns to protect against.
Threat Actors Abuse Microsoft's Vetting Services
Discover how threat actors are abusing Microsoft’s “verified publisher” status. Learn about the abuse of these vetting services and how to protect against them.