No Free Rides With Your OAuth Tokens

By Ian Sharpe, Product Leader at AppOmni

It’s just another typical Wednesday in May. You’ve received an email from one of your contacts, someone with whom you haven’t spoken to in years. They’ve shared a Google Docs with you. It seems a bit odd, but you’re curious, so you click on the “Open in Docs” button. You’re prompted to allow “Google Docs” the ability to read, send, delete, and manage your email — and also manage your contacts. Your ‘spidey senses’ begin to tingle and you pump the brakes.

Remember this one? It was 2017 and 1 million Gmail users were impacted by this phishing attack. Google responded promptly and was able to stop the campaign in approximately an hour. At the time, this was a unique phishing attack vector, and rather than focusing on user credentials, it targeted OAuth tokens.

These attack vectors have continued to increase in popularity and frequency. Illicit consent grants have been seen across Microsoft O365 and Azure AD ecosystems. Note that if you’re a Microsoft shop, you can read more about their recommendations for detection and remediation here. More recently, Git analytics firm Waydev was the victim of one of these types of attacks. OAuth tokens for Github and Gitlab for two of the firm's clients were stolen, resulting in compromised codebases and source code. Suffice it to say, this is likely not the last time we will see these unfortunate headlines.

You may be thinking of all the systems and services that use OAuth in your environment — and the potential risks they pose to your organization. Before you get too far down that rabbit hole, let’s take a moment to better understand why this is worth your attention.

It’s the path of least resistance for your users.

Your team members have likely leveraged these grant workflows in their personal lives. More than likely, they’ve done it a number of times. For them, connecting their Google account to insert(random_app) has been seamless and easy. This workflow is now familiar to them, and connecting a new application that requests access, is, in their eyes, typical behavior. They’ve been conditioned to allowing access without worry of serious risk or consequences.

While we security practitioners know that not all apps are created with admirable intentions in mind, correcting this existing perception is challenging to overcome. We might share guidance to our family and friends that they should practice good security hygiene and regularly check the list of applications that have access to their accounts and remove those that are no longer used.

Family and friends are now educated(ish)! Now comes the responsibility of protecting your workforce and company. No small feat, it’s like tackling Mount Hood. It can be done but it’s slow, steady, and very deliberate. With the sprawl of applications and continued adoption of clouds, prioritization is important.

OAuth 2.0 is the industry-standard protocol for authorization.

There is little contention that OAuth has become the defacto framework for authorizing APIs. With a keen focus on client-developer simplicity and specific authz flows for web apps, desktop apps, mobile phones, and — your company’s refrigerator. The framework continues to evolve and has some very powerful and beneficial security features.

I’m personally a big fan of Okta’s API access management capabilities. They have capabilities around scoped access tokens that provide more access granularity and shorter token life spans. And they can be generated and retrieved using an API. I also enjoyed Michal Trojanowski’s talk on When Basic OAuth is Not Enough, who discusses device code grant type, token exchange, and proof key for code exchange OAuth 2.0 extensions.

Check, the baseline has now been loosely set.

We can hopefully agree that it’s important to understand OAuth usage in your environment. Now comes the fun part: discovery. As with any security program worth its salt, it’s all about prioritizing and scoping. Taking a two-pronged approach could be an advantageous option.

The first prong involves identifying which customer or forward-facing touchpoints use OAuth. Do you have the security design fundamentals in place? Have you provided solid guidance to your dev team on best practices? Can you help to empower them with security services that can remove incorrect interpretations of the framework?

The second prong is identifying how your workforce is using business critical SaaS applications that leverage OAuth. What do they connect to? Are these connections creating gaps in your visibility or opening you up to additional risk?

These discovery questions and approaches are in no way meant to be thorough, but I do hope they get the creative juices flowing and inspire you to take a deeper look into these risk areas as you plan for 2020. If your journey includes SaaS security, reach out to us at AppOmni, we would happily assist.

Ian Sharpe is a product leader at AppOmni and enjoys the challenges of being a security practitioner.

• RFC6819 - OAuth 2.0 Threat Model and Security Considerations
• OAuth 2.0 Security Best Current Practices
• The OAuth 2.1 Authorization Framework
• https://oauth.net/2/