We show how to use OAuth 2.0 securely when using a Classic Web Application, a Single Page Application, and a Mobile Application as clients. For each of these clients, we elaborate on the overall design, implement that design, and touch upon common security mistakes. You can exploit these mistakes by deploying the damn vulnerable OAuth 2.0 applications.
In this article, we elaborate on common security mistakes that architects and developers make when designing or implementing OAuth 2.0-enabled applications. The article not only describes these mistakes from a theoretical perspective, but also provides a set of working sample applications that contain those mistakes. This serves three purposes:
The article is structured as follows. Section Background introduces the OAuth 2.0 Protocol using a running example. The subsequent sections show how to use OAuth 2.0 when using a Classic Web Application, a Single Page Application, and Mobile Application as clients. For each of these sections, we elaborate on the overall design, implement that design using the MEAN stack, and touch upon common security mistakes. Section Checklists summarizes this article in the form of checklists for architects, developers, and testers. Finally, Section Conclusion concludes.
Note: the mistakes are common across technology stacks; we use the MEAN stack for illustration purposes only.
Our canonical running example consists of a web site that enables users to manage pictures, named gallery
. This gallery application is similar to flickr.com
in the sense that users can upload pictures, share them with friends, and organize those pictures in different albums.
As our gallery application became quite popular, we got requests from various companies to integrate with our gallery
application. To that end, we decided to open up the REST API
that forms the foundation of our application towards those companies. These companies use the following types of clients:
photoprint
.mypics
.mobilegallery
.livepics
.As we are concerned about security, users should be able to give those third-party applications permission to access their pictures without providing their username and password to those applications. It seems that the OAuth 2.0 protocol might help achieve our goals.
OAuth 2.0 is a standard that enables users to give websites access to their data/services at other websites. For instance, a user gives a photo printing website access to her pictures on Flickr. Before performing a deep-dive into the specifics of OAuth 2.0, we introduce some definitions (taken from auth0):
gallery
.In OAuth 2.0, the interactions between the user and her browser, the Authorization Server, and the Resource Server can be performed in four different flows.
Do not worry if you do not understand the flows right away. They are elaborated upon in detail in subsequent sections. What you should remember is that:
You make many design decisions when architecting an OAuth 2.0 enabled application. Read Architect: Major Design Decisions to understand the security impact of major design decisions, such as the selected OAuth 2.0 grant, the use of refresh tokens, and integrating with third parties.
Once you selected the grants, you need to make various local design decisions as well as implementation decisions.
In this article, we showed how to use OAuth 2.0 securely when using
Partially taken from https://oauth.net/2/.