Do You Know Your OAuth Flows?
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:
Implicit Grant (Deprecated)
Note: To follow best practices, Implicit Grant is no longer supported. All new security profiles must use Authorization…
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.
draft-ietf-oauth-v2-1-02 - The OAuth 2.1 Authorization Framework
OAuth Working Group D. Hardt Internet-Draft SignIn.Org Intended status: Standards Track A. Parecki Expires: 16…
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
© 2nd Sight Lab 2021
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
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts