Anti-OAuth Alliance
Description
OAuth is a subversive family of design concepts that can be utilized to offer an authorization framework for services. This framework encapsulates, but for the most part leaves unspecified, how authentication is to be implemented, while also superficially defining what subsequent stages of trust involve. These concepts have a large attack surface, and when incorrectly combined lead to a slew of issues. These issues are common, and even large companies with experienced developers to implement these concepts, such as Facebook or Github, are known to have repeatedly made mistakes opening up their users or third party developers to attack.
Services providing APIs built upon an OAuth-based foundation are generally insecure or used insecurely, and more importantly, are frequently unable to provide APIs that are usable in most circumstances. We provide two articles elaborating on this:
Despite all the issues, large vendors who are offering non-enterprise services and do not care about their users or third party developers prefer OAuth for their agendas with which OAuth aligns well. Many consultants also prefer it when OAuth is used, as it increases the demand for their consulting services to tame OAuth and provide something remotely secure or usable. Don't be fooled by those pushing OAuth to satisfy their own agendas or who personally benefit from how problematic OAuth is.
Due to all these problems, as a matter of principle, we strongly recommend not to try to build API services upon the flawed authorization concept OAuth is popularizing. It is best to use well understood authentication protocols coupled with well thought out business practices, and leave authorization to administrative menus where it belongs. Below we list some resources that can aid in designing authentication for API services, as well as other components crucial to providing an HTTP-based API.
It is our hope that those developers reading this will aim to understand what they truly want to provide the market with, and avoid the fad and bias currently promoting OAuth. We also hope our readers will tell vendors of services they use that they demand access to something saner and more usable.
The Alliance
Show your support for the Anti-OAuth Alliance by not using OAuth, and convincing others to switch to something better. If you have created good material regarding not using OAuth, write a comment in to us on our most recent article, and we will add a link to your material.
Imagery
Feel free to use our imagery in any material you create which aims to demote the use of OAuth.
Key problems commonly found with OAuth systems
The problems enumerated below and some workarounds are elaborated upon within our aforementioned OAuth articles.
- Though OAuth does avoid the need to send user-level credentials back and forth, it does so in such a way that application-level credentials are easily obtainable in transit, a vulnerability which can be several orders of magnitude worse.
- The use of application-level credentials, rather than user-level or organization-level, mean that a business providing an application making use of an OAuth-based service can be crippled at any time by having their plug pulled.
- Application-level credentials mean that most services limit the amount of API usage allowed at the application-level, holding vendors responsible for their users’ actions and penalizing completely unrelated users and organizations for each others’ actions.
- Application-level limits mean that vendors can not scale their businesses effectively.
- Application-level credentials make OAuth unfriendly to open-source and on-premises software, as application credentials can be extracted from the source code or a binary.
- Application-level credentials mean that OAuth-based services cannot provide a traditional API guarantee along with their software package, as the API availability is dependent on the credentials of any third-party vendors remaining valid.
- Working around the application-level issue requires every consumer to apply for their own separate credentials, a process which is not possible to automate and which is usually difficult, time-consuming, and often involves manual intervention or approval.
- OAuth tokens generally expire automatically after a certain amount of time, requiring users to reauthenticate periodically, violating the idea of high availability, and making it impossible for automated tasks to be carried out reliably without user intervention.
- In order to use OAuth effectively and reliably, applications may end up having to store users’ credentials anyway, defeating the purpose of token-based authentication to begin with.
- Most OAuth-based APIs do not offer a way to manage information on behalf of all users within an organization, making it effectively useless in the enterprise market.
- The only OAuth-based services which have thriving ecosystems are ones which are geared solely for individual users rather than enterprises.
- Most OAuth-based APIs are so limited that they effectively make it impossible to do anything beyond reimplementing a subset of their already existing user interface.
- OAuth assumes from the start that all other applications are inherently untrustworthy rather than giving administrators the tools to make and implement their own determination.
- OAuth does not treat applications with a mutual level of distrust, instead, all applications making use of an OAuth-based service are treated as untrusted, yet those same applications are required to treat the service as trusted.
- The connection is initiated by a application that OAuth itself considers untrustworthy, thus making the entire interaction suspect.
- OAuth makes it difficult for average developers to prevent cross-site request forgeries.
- OAuth makes it difficult for an application making use of it to whitelist trusted URLs, as the URLs used for the process are often diverse, varying, and often modified.
- Despite making it impossible for applications to whitelist it, OAuth requires that either a single URL or a very limited number of URLs be whitelisted up front before an application can make use of it, often leading developers to create insecure workarounds to ensure proper redirection and remain future proof.
- The typical login flow involves going through redirects to external sites, making it difficult for users to differentiate between a genuine login form and a phishing attack.
- The typical login flow involves going through redirects to external sites, increasing the chance that a man-in-the-middle attack can be performed.
- A redirect URI is usually required, and often only one is allowed, forcing developers to rely on a single point of failure.
- A redirect URI is usually required up front, preventing vendors from being able to easily deploy their platform on separate URIs for each client.
- A redirect URI is usually required, despite the fact that an application may not even be web-based, and thus will not even have a URI endpoint.
- The typical login flow often requires a modern browser with JavaScript support, something which is difficult to make use of correctly in an application which is not browser-based.
- A redirect URI is usually required, and often only one is allowed, increasing the chance of the average developer making mistakes which could lead to cross-site request forgeries or other vulnerabilities.
- Many developers assume that simply “using OAuth” means that their system is automatically secure, even if they are generating tokens which are easily predictable or have other insecure components.
Recommended Books
- Secure Programming Cookbook by John Viega and Matt Messier. A great book covering many topics on how to create secure software and understanding the purpose and use of various cryptographic components. Includes material on HMAC as well as random number generation.
- Cryptography Engineering by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno. A good book covering how to fit together various cryptographic components to create a secure system. Also covers several important implementation details and issues to consider when creating a secure system.
- HTTP Developer's Handbook by Chris Shiflett. Covers how applications should make use of HTTP including authentication and authorization concepts.
- HTTP: The Definitive Guide by David Gourley, Brian Totty, Marjorie Sayer, Anshu Aggarwal, and Sailu Reddy. Covers nearly every aspect of HTTP itself and ideas underlying the major parts of it, quite useful for designing your own HTTP clients and servers.
- Bulletproof SSL and TLS by Ivan Ristic. A great book which discusses how web servers and applications running on them are attacked and how to secure them. Covers many important implementation details for secure and usable web-based application design.
Other
If you like would like to support the Anti-OAuth Alliance or anything else on Insane Coding, please consider making a donation.
