Panel: What Happens When Applications Don't Use the Identity Standards We Have Built

OAuth 2.0 is a widely adopted standard for authorization, but it can be complex to implement correctly. It's not uncommon for developers to have difficulty understanding the nuances of the OAuth 2.0 flow and instead rely on simpler approaches such as using API keys in "god mode."

OAuth 2.0 can be difficult to set up and configure, especially for developers who are new to the standard. It involves creating an OAuth 2.0 client, setting up redirect URIs, and managing access and refresh tokens, which can be confusing and time-consuming. Additionally, the standard requires developers to handle user authentication and authorization separately, which can be difficult to understand for those who are not familiar with the concepts.

Many developers may not understand the security benefits of OAuth 2.0 over API keys. OAuth 2.0 allows for fine-grained access control, enabling developers to limit access to specific resources and actions. In contrast, API keys provide more open access, allowing all actions on all resources. Developers may be inclined to use API keys instead of OAuth 2.0 because they are simpler and easier to implement, but they don't offer the same level of security.
Developers may find it hard to understand the standards, and may end up using an inconsistent approach.

The panel will discuss these reasons and other potential causes for why developers may not be using OAuth 2.0 correctly, and provide recommendations for how to overcome these challenges. We will highlight the benefits of OAuth 2.0, such as improved security and the ability to provide fine-grained access control, to encourage developers to adopt the standard. Additionally we will give examples of real-world attack scenarios that could have been avoided if the application was using OAuth 2.0.