Oh! Auth: Implementation pitfalls of OAuth 2.0 & the Auth Providers who have fell in it

By Samit Anwer on 28 May 2019 @ Securityfest
📹 Video 🔗 Link
#web-security #iam #appsec
Focus Areas: 🔐 Application Security , 🪪 Identity & Access Management , 🌐 Web Application Security

Presentation Material

Abstract

Since the beginning of distributed personal computer networks, one of the toughest problem has been to provide a seamless and secure SSO experience between unrelated servers/services. OAuth is an open protocol to allow secure authorization in a standard method from web, mobile and desktop application. The OAuth 2.0 authorization framework enables third-party applications to obtain discretionary access to a web service. Built on top of OAuth 2, OpenID Connect is a helpful “identity layer” that provides developers with a framework to build functional and secure authentication systems. 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. This work discusses common malpractices that relying party devs perform when implementing OAuth/OpenID based relying party solutions, and the goof-ups that authorization servers can introduce—including a case study on OAuth authorization providers and vulnerability in Microsoft’s authorization server (login.windows.net).

Presented at Security Fest 2019.

AI Generated Summary

The talk provides a technical overview of the OAuth 2.0 authorization framework and its associated security vulnerabilities, with a focus on attacks relevant to native and web applications. It explains OAuth’s purpose in delegated authorization, detailing core entities (resource owner, client, authorization server, resource server) and the authorization code and implicit grant flows. A significant portion covers attacks exploiting implementation weaknesses in native applications.

Key attacks discussed include the authorization code interception attack, where a malicious app registers the same custom URL scheme as a legitimate app to steal the authorization code during the redirect. The mitigation is using claimed HTTPS scheme redirect URIs, which are uniquely owned by the application. The Proof Key for Code Exchange (PKCE) extension is presented as a critical defense, requiring the client to prove possession of a secret code verifier when exchanging an authorization code for a token, preventing code redemption by an attacker who intercepts it.

Other attacks covered are cross-site request forgery (CSRF) on the client’s redirect URI and open redirect vulnerabilities. CSRF is mitigated by using an unguessable state parameter in the authorization request and validating it upon response. Open redirects can lead to token leakage via URL fragment inheritance; the mitigation is strict validation of the redirect_uri parameter and avoiding wildcard patterns.

The talk concludes that proper implementation of PKCE for native apps, rigorous state parameter usage, and strict, non-wildcarded redirect URI registration are essential practical takeaways to secure OAuth deployments against common interception and redirection attacks.

Disclaimer: This summary was auto-generated from the video transcript using AI and may contain inaccuracies. It is intended as a quick overview — always refer to the original talk for authoritative content. Learn more about our AI experiments.