Do You Know Your OAuth Flows?

Choose the correct flow for the application you’re building

Teri Radichel
Mar 23 · 3 min read

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:

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.

Teri Radichel — Follow me @teriradichel


Want to learn more about Cybersecurity and Cloud Security? Check out: Cybersecurity for Executives in the Age of Cloud on Amazon

Need Cloud Security Training? 2nd Sight Lab Cloud Security Training

Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.

Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts

Cloud Security

Cybersecurity in a Cloudy World

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store