OAuth 2.0 and OIDC Implementation Flaws — Web Application Security

OAuth 2.0 is an authorization framework that lets a user grant one application limited access to their data on another, without sharing their password. OpenID Connect (OIDC) layers authentication on top, so the same flow can also prove who the user is. The protocols are sound, but they are frameworks with many options, and most real-world breaches come from implementation mistakes rather than protocol flaws.

Analogy🏏Cricket

🍳 Think of it like cooking: A recipe can look flawless on paper, but a head chef only truly judges the dish by tasting the finished plate, because heat, timing, and the actual oven reveal problems the written method never shows. Just as tasting the cooked result catches what reading the recipe cannot, DAST probes the running application and catches the misconfigurations and runtime behaviour that reading the source cannot. This reveals DAST's stance: it judges the dish as it is actually served, not the recipe as it was merely written.

This lesson focuses on the errors that recur: skipping the state parameter and enabling CSRF on the login flow, accepting an unvalidated or open redirect_uri, and confusing authorization with authentication. Each is a case of omitting a check the specification calls for. Understanding what each parameter defends against turns a confusing flow into a set of concrete, verifiable safeguards.

Analogy🏏Cricket

💰 Think of it like finance: A real audit that actually attempts a sample transaction proves beyond doubt whether a control can be bypassed, with little room for a false alarm, but it can only test the accounts and processes the auditors actually reach. Just as a hands-on audit yields high-confidence, low-false-positive results yet is bounded by what it examines, DAST yields high-confidence findings about real exploitability yet is bounded by the surface it can reach. This reveals its trade-off: what it confirms is solid, but it only confirms what it manages to touch.