Presentation Material
Abstract
Since the beginning of distributed personal computer networks, one of the toughest problem has been to provide a secure SSO and authorization experience between unrelated servers/services. The OAuth 2.0 authorization framework enables 3rd party apps to obtain discretionary access to a web service. Built on top of OAuth, OpenID Connect is a helpful “identity layer” that provides developers with a framework to build an authentication system. In this race of providing OAuth/Open ID Connect based access to assets, authorization service providers have been forced to release half-baked solutions in the wild because of which relying parties and users face myriad of issues ranging from authorization code compromise (unauthorized resource access) to account takeovers. In this talk we will discuss common malpractices that “relying party” and “authorization service provider” developers perform when implementing OAuth/OpenID based solutions. We will learn the attacks that can happen thereof and mitigation.
AI Generated Summary
The presentation examined security vulnerabilities in OAuth 2.0 implementations, focusing on token-based delegated authorization. It detailed the protocol’s core entities—resource owner, client, authorization server, and resource server—and compared grant types, advocating for the authorization code flow over the implicit grant due to superior security, particularly the avoidance of access token exposure via the browser.
Key attacks discussed included the authorization code interception attack on mobile clients using custom URL schemes, where a malicious app registers the same scheme to steal the code. Mitigation involves using Proof Key for Code Exchange (PKCE), which binds the code to a verifier known only to the legitimate client. A case study highlighted a faulty PKCE implementation in Microsoft’s identity provider that failed to validate the verifier.
Other covered attacks were CSRF via open redirects, where an attacker manipulates a client’s redirect URI to steal tokens, mitigated by strict redirect URI validation and the state parameter. Phishing via attacker-controlled redirect URIs exploited user trust in the authorization server, requiring the server to warn users of external redirects. The mix-up attack occurred when a client used the same redirect URI for multiple OAuth providers, allowing a malicious provider to redirect authorization to a legitimate one, mitigated by using unique redirect URIs per provider.
Practical takeaways emphasized that native applications must implement PKCE, clients must validate redirect URIs and use anti-CSRF tokens, and developers should avoid implicit grants and open redirects. The talk concluded by recommending thorough review of OAuth 2.0 RFCs, especially security considerations, for robust implementation.