Do You Know Your OAuth Flows?

Choose the correct flow for the application you’re building

This is one of my posts on Google Security, Application Security, and Secure Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

I get a lot of questions about authentication and authorization on my cybersecurity consulting calls. I’ve also seen presentations on JWT, OAuth, and OpenID Connect missing critical aspects of secure implementations. When I’m performing penetration tests on AWS, Azure, and GCP, I often find mistakes in these areas. Make sure you understand all the details of this critical security control to avoid leaving your application open to attacks.

Sometimes developers mistakenly think because they are using JWTs, OAuth, and OpenID connect, they are secure. These acronyms are thrown around a lot but just implementing these technologies is not enough. You’ll need to know how to do so correctly and securely.

One important thing you’ll want to understand is which OAuth grant type, also known as an OAuth flow, to use for the type of application you are building. Different flows have different purposes, strengths, and weaknesses. The best practices have also changed over time as application security professionals discovered new and improved techniques and hackers discovered ways to attack the original implementations.

For example, one of the OAuth flows is called the implicit flow. Best practices have recommended against using this flow for quite some time, yet it is still in use in some places. You could technically use it under certain circumstances, but it requires a lot of caveats to get it right. It’s not worth the risk.

I was just helping a client using the Google Cloud Platform and found a sample JWT implementation example using the implicit flow. I’ve stated this before in many presentations, but don’t assume just because you pulled example code off cloud provider documentation that it is following all security best practices and guidance. From the documentation at the time of this writing:

https://cloud.google.com/api-gateway/docs/authenticating-users-jwt

In another example, Login with Amazon has wisely deprecated this flow:

The current OAuth 2.1 draft specification omits the Implicit and Resource Owner grant types.

In most cases, you’ll want to use the Authorization Code + PKCE.

Note on PKCE:

Historic note: Although PKCE [RFC7636] was originally designed as a
mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications and other confidential clients.

See the specification for details related to native applications, machine-to-machine access, and other scenarios.

Keep an eye on changes as this specification evolves to protect your applications from authentication and authorization attacks and prevent security vulnerabilities.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2021

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab