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

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. OpenID Connect can perform identity authorization and provide basic profile information for different clients, from web and mobile apps to JavaScript clients. 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. The key to adding authorization or SSO measures to your app is to ensure you are balancing security with usability. Developers likely make trade-offs when making decisions about specific implementation - and there are a lot of decisions to make. Developers still want to double down on security to avoid flaws in 2.0, paying attention to things like session management, encryption/obfuscation of stored data and IDs, and securing the source code of an app. In this work we will discuss common malpractices that relying party devs perform when implementing OAuth/OpenID based relying party solutions. However, all is not in the hands of relying party developers, the authorization service providers have a big role to play as well. There are mainly 4 entities involved in a typical OAuth setup, they are – relying party/client, user/resource owner, resource provider, authorization server. In this work, we discuss the goof-ups that each of these entities can introduce with special focus on vulnerabilities that the authorization server can introduce. The highlight - We present our case study on OAuth authorization providers and detail the issues we found in their solutions. This includes vulnerability in Microsoft's authorization server - login.windows.net.

Presented at Security Fest 2019.

About Samit Anwer

Samit Anwer is a Web and Mobile Application security researcher. Soon after completing his Master's degree from IIIT, Delhi in Mobile and Ubiquitous Computing he joined Citrix R&D India as a Product Security researcher. He is actively involved with vulnerability research in popular Web/Mobile apps and has responsibly disclosed several security vulnerabilities with Google Cloud Print API, XSS filter evasion on IE 11/MS Edge, code execution on Microsoft Windows 10, Microsoft's OAuth 2.0 implementation and buffer overflows on MS Edge/IE 11. He is an active member of the Null Bangalore Chapter, IEEE community and has spoken on various security topics at the following venues: DEFCON China, Beijing (2018) BlackHat Asia, Singapore (2018) AppSec USA, Orlando (2017), CodeBlue, Tokyo (2017), c0c0n X, Kerala (2017) and Null meets (2015, 2016, 2017, 2018) He has previously published papers at the following venues: Chiromancer: A Tool for Boosting Android Application Performance [MobileSOFT Conference 2014, Hyderabad, India], http://dl.acm.org/citation.cfm?id=2593918 Detecting Performance Antipatterns before migrating to the Cloud [IEEE CloudCom 2013, Bristol, U.K.], http://dl.acm.org/citation.cfm?id=2568531 Performance Antipatterns: Detection and Evaluation of their Effects in the Cloud [IEEE Services 2014, Anchorage, Alaska], http://ieeexplore.ieee.org/document/6930605/ His technical interests lie in using static program analysis techniques to mitigate security and performance issues on mobile/web apps, breaking web/mobile apps, and researching on cutting edge authentication and authorization mechanisms.