OAuth Authentication Fundamentals for SecOps

What is OAuth?  What role does it play in granting permissions?  How are attackers making use of and even abusing OAuth permissions? What OAuth Authentication Fundamentals every SecOps should know?

One of the fundamental aspects of authentication to end-user systems is to have the correct permissions applied to your user account.  For decades now, logging into an end-user system with your user credentials allows permissions to access various resources.  If you are logging into an on-premises Active Directory infrastructure, this may mean you get access to a file share or email inbox.

In this day and age of public cloud environments, including cloud Software-as-a-Service (SaaS), a form of permissions delegation and authorization is used to allow applications to assume users’ permissions without knowing their password.  It is known as OAuth.

What is OAuth?

To begin with, let’s take a closer look at what OAuth is. Since the beginning of computerized systems, it has been challenging to authenticate and authorize users to dissimilar systems. This challenge for authentication and authorization has led to the concept of single sign-on (SSO).  Single sign-on provides an end-user the ability to log in once and have the ability to access all resources without reauthenticating.

OAuth History

OAuth was born from the need to provide single sign-on capabilities to end-users who required accessing resources across many environments.  Additionally, modern applications and the explosion of public cloud services and data located in the cloud have emphasized the need to provide users with the ability to share information from their cloud accounts with third-party applications.  Twitter, Google, and other cloud service providers have strongly supported the OAuth standard, which was released as an open standard in 2010.

Most of the major cloud service providers are making use of the OAuth standard.  These include Amazon, Facebook, Instagram, Linked In, Microsoft, Netflix, PayPal, Apple, and others.  It has evolved into OAuth 2.0 that is generally used by today’s cloud service providers and implements new security capabilities into the standard.

Rather than being an authentication protocol, OAuth is an authorization protocol.  What is the difference between authentication and authorization?  In basic terms, authentication validates a user’s identity.  Authorization provides permissions for a user to access a resource.

OAuth Authentication Fundamentals: RESTful APIs and Permissions Delegation

You will see a great deal of information about how OAuth denotes permissions delegation.  What does this mean?  As we defined earlier, authorization allows an end-user to be granted permissions on a specific resource they attempt to access.

Modern application development is adopting the microservices approach to building out infrastructure backing modern applications.  It is also known as building cloud-native applications.  Cloud-native applications take monolithic applications structured in the typical web server, application server, and database server architecture and break those components up into many smaller applications and components.

Cloud-native microservices architecture makes use of Application Programmable Interfaces (APIs).  APIs are the way that applications get information from the various microservices that make up modern applications.  Public cloud environments use APIs to get information and interact with the various application subcomponents.   As a case in point, when you interact with the dashboard of your public cloud IaaS or SaaS environment, the dashboards are using APIs in the background to talk to the infrastructure components.

Providing Third-parties Access to Data

One of the essential roles that APIs play for cloud environments is providing third parties access to data.  It allows for the efficient exchange of information. Most of us don’t realize when we are interacting with APIs.  Generally, we see API interactions on our smartphones and other mobile devices.

When you see messages pop up on your smartphone when installing a third-party application or when an application requests to use various sensors on your smart device, this is an API.  An example of the behavior can be seen in the below message when using Google Maps.  It helps to demonstrate that APIs can be used as security gatekeepers.

A prompt for security permissions via API

Each time a third-party application requests APIs that are system-centric to your mobile device, the mobile device will display a prompt for approval of the permissions request, such as using the GPS data via the underlying system API.  While APIs can act as security gatekeepers that allow granting permissions to exchange information, the problem with this type of permissions approval is long-lasting.   While API permissions are easily revoked in most sites such as Google, Facebook, and others, permissions that have been granted are easily forgotten.  How does this relate to OAuth permissions delegation?

How OAuth Is Used to Access APIs

As an example, Google uses OAuth 2.0 credentials to delegate permissions to API resources.  All applications follow the same basic pattern to access a Google API using OAuth 2.0.

1. OAuth 2.0 credentials are obtained from the Google API console
2. Obtain an access token from the Google Authorization Server
3. Scopes of access granted from the user are examined
4. The access token is sent to the API
5. Refresh the access token if needed

The OAuth authorization process to access Google APIs

Let’s take a more detailed view of each step in the OAuth permissions delegation process used by Google’s APIs.

1.  OAuth 2.0 credentials are obtained from the Google API console

Application owners obtain OAuth 2.0 credentials from the Google API Console.  These are in the form of client ID and a client secret known by both Google and your application.  These specific values will vary depending on the application type.

2.  Obtain an access token from the Google Authorization Server

The next step is where things get interesting from a security permissions perspective.  Before a third-party application can access private user data using the Google API, it must obtain an access token that grants access to the Google API.  These access tokens are not a “one size fits all.”  There are varying degrees of permissions based on a very critical parameter called scope.

The scope defines the type and level of access that a third-party application is requesting.  Various API resources, including Google, Microsoft, and others, define a set of scopes that applications can request.  OAuth 2.0 provides different grant types that can be used by third-party applications and web applications that are implementing OAuth.

The application can request access to various resources and operations based on the scope parameter.  The level of access is decided upon during the access-token request operation.  The third-party application will include one or more values inside the scope parameter as part of the request.

As a user, you may see the request for you to log in with your Google account. Then you are prompted to grant the permissions that are requested by the application. The process of the user giving permissions to a third-party application is called user consent. Once a user grants even one permission to the application, the Google Authorization Server provides the application with an access token and a list of the scopes of access granted by the token.  If the end-user grants no permissions, an error is returned to the application.

Well-written third-party applications following OAuth best practices will request permissions incrementally. This means that if a third-party application needs access to different parts of your Google account, access will only be requested when required.

It is crucial to understand and note, the requested token does not require knowledge or access to the user’s password.  Additionally, access tokens bypass two-factor authentication configured on an account. This is important to consider from a security perspective, especially when allowing end-users to grant permissions requests to third-party applications as part of a cloud SaaS environment.

3.  Examine scopes of access granted by the user

The scopes returned in the access token are compared to the scopes required to access application features and functionality.  The application should disable features and functionality unable to function without access to the related API.

4.  Send the access token to an API

Once an authorization token is obtained from the Google Authorization Server, the token is sent to the Google API as an HTTP authorization request header.  The access tokens are only valid for a specific set of operations and resources defined in the scope of the token as mentioned earlier.  You can’t use a token that is granted for one API and use this for another API.  For example, if you are granted a token for Google Gmail API, you can’t use this token for Google Calendar and its API.  This makes the process very granular.

5.  Refresh the access token if needed

The access token that is granted by the Google Authorization Server has a limited lifetime.  However, applications can request a refresh token when needed.  An application can request a new access token by using the refresh token to make the request.

Aggressive App Permissions

Have you ever stopped to take a look at the permissions that even standard smartphone apps request?  It can be eye-opening to see the number of high-level permissions that even “normal” apps need to be delegated when installed on your smart device.  These can include the following:

1. Mail Read
2. Health Data
3. Fitness Data
4. View people in your account
5. Send an email on your behalf
6. Edit your Calendar
7. Read your email
8. Run when you aren’t present
9. Manage your contacts
10. View files in your Cloud Storage
11. Delete your Cloud Storage Files
12. Connect to external services
13. Full account access

As most are accustomed to simply “clicking allow” on permissions requests by third-party applications, we can grow accustomed to requested permissions.  With this being the case, attackers may easily persuade end-users to grant the high-level permissions requested by a malicious application.  What methods are used by attackers to abuse OAuth authorization?

OAuth Abuse

While OAuth in itself has measures implemented that can help with security, attackers can abuse OAuth in various ways for malicious purposes.  Abuse of OAuth can happen in many different ways.  These include:

• Malicious applications using OAuth to retrieve account data
• Access token leakage
• OAuth protocol and implementation security weaknesses

Malicious applications using OAuth to retrieve account data

While the concept around OAuth helps ensure third-party applications are granted expressed permissions only with user consent, attackers can craftily impersonate legitimate third-party applications to access account data.  As an example, an attacker could create a malicious application posing as a legitimate app, request OAuth tokens to access account data, then use this information to leak data from a user’s account.

As mentioned earlier, OAuth tokens do not require knowledge of a user’s password and also bypass two-factor authentication.  Another essential consideration is OAuth tokens have to be explicitly revoked from an application.  As a great example of how dangerous this can be, Kevin Mitnick demonstrated how easy it is for an attacker to exploit OAuth authorization to grant a malicious ransomware application access to a cloud mailbox.   It underscores the importance of organizations carefully considering their stance of allowing third-party application installations in cloud SaaS environments like Google Workspace and Microsoft 365.

Access token leakage

Access token leakage is a type of OAuth abuse that often affects social media networks.  Applications that integrate with social media networks such as Facebook may have weak security settings.  Third-party applications that integrate with Facebook gain user tokens when a user authenticates an application.  Collusion networks collect OAuth tokens for applications that may be using implicit mode for OAuth.  These networks are reputation manipulation services that provide likes and comments on Facebook and other services based on cooperation with other users/networks and trading likes for likes.  These tokens are then used to conduct activities on behalf of applications and colluding accounts.

OAuth protocol and implementation security weaknesses

It has been noted that certain applications leveraging OAuth do not require application secrets and are susceptible to access token leakage and abuse.  There are various ways that attackers could harvest OAuth tokens employing eavesdropping, cross-site scripting, or social engineering techniques.  Once an attacker has access to a compromised OAuth token, they can access the end user’s personal information.  Additionally, they can use the OAuth token to conduct other malicious activities such as spreading malware on behalf of the compromised user.

Protecting your organization’s cloud data

While OAuth authorization provides a modern way for applications to access private data as contained in modern applications or cloud service provider environments, organizations must bolster the security of business-critical systems and data in other ways.  Attackers are keenly interested in compromising cloud environments, as many organizations leverage the cloud for business-critical operations, especially now with a highly distributed workforce.

As attackers can use social engineer, phishing emails, and malicious applications to compromise cloud environments, including cloud SaaS, controlling the applications used by your end-users is extremely important.  SpinOne is a solution that uses application control to enforce which third-party applications can integrate into your Google Workspace or Microsoft 365 environment. SpinOne maintains a behavior database and reputation analysis of thousands of applications so you know which applications are safe.

SpinOne Provides Robust Cybersecurity Features

• Third-party apps control
• Domain data auditing
• Visibility to shared data
• Ransomware protection
• Automated enterprise-class backups

Using a proactive approach of which applications can integrate with your cloud SaaS environment provides excellent protection against OAuth abuse by malicious applications.

Concluding Thoughts

We certainly live in the day and age of modern applications that span on-premises, cloud, and hybrid environments.  Microservices are the new normal of application development. Application components communicate by using modern APIs.  Applications are authorized to communicate with end-user data by using OAuth tokens.

OAuth is a robust cloud authorization protocol that allows delegating permissions to third-party applications on behalf of the end-user. Attackers are looking for ways to abuse OAuth authorization and often use social engineering and malicious applications that pose as harmless apps to compromise your data, steal information, or even introduce ransomware.

Using AI-enabled solutions like SpinOne allows organizations to ensure attackers cannot use malicious applications to compromise OAuth tokens. It also protects your cloud SaaS environment from ransomware. Check out demo for SpinOne here.