OAuth 2.0 is the second version of Open Authorization Framework, the industry-standard delegation protocol for authorization.
What are the main use cases?
Generally, OAuth provides to clients a „secure delegated access” to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials.
1. Accessing user data from data providers (e.g. Facebook)
OAuth is widely used by third-party applications (e.g. SaaS platforms) to access Internet users’ protected data with their consent, but without revealing their password.The data includes for example the e-mail address and contacts list on Google, friends list on Facebook, etc. If you were ever asked by web or mobile application to give permissions to access your personal data, you have probably used OAuth 2.0.
2. Storing and providing user data
The above paragraph describes OAuth 2.0 from the data consumer perspective, but there is also the other side of OAuth that you may want to implement. You may want to become a data provider like Google or Facebook in the above example. That is a common solution when you store information about your users and want to share it with third-party applications on behalf of users, only if they agree. The third-party applications that need to access the information must be authorized by users and then can read data directly from your server.
3. Accessing and providing user data
OAuth 2.0 can be also used in a hybrid scenario in which the application is both the data provider and data consumer at the same time. Imagine an application that stores specific users’ data (e.g. health information) that is going to be shared with third-party applications. From this perspective, the application is a data provider.
Additionally, to increase the UX, the application allows users to create an account using Google or Facebook account and becomes the data consumer. It shares the data with third-party applications and is the third-party application for Google or Facebook.
What are the security concerns?
Whenever you handle users’ data or rely on the responses from the other OAuth data providers you must implement security mechanisms that will protect your users from leakage of their data, or even account hijacking.
The OAuth 2.0 is used to delegate access to users’ data so the the first answer that comes to mind is the user’s personal data and the biggest threat is its leakage. That was the case covered by researchers from University of Hong Kong who checked 600 popular mobile applications that integrate with Google, Facebook or Sinu (Chinese) and found that 41% of them are vulnerable to user data leakage, exposing the details of over 1 billion users (based on the number of downloads). Some applications exposed rather non-sensitive information like music playlists, but others exposed such information like personal income, expenses or dating history.
However there is another threat that in some cases can have even bigger impact than data leakage. Have you ever considered what other kind of resources can OAuth delegate access to? Besides the data, third-party applications can also get access to functions and execute them on behalf of the user (e.g. publish post). Not only this can cause many problems to your users or even use their accounts to spread phishing attacks, but also can ruin your business. Basically, insecure OAuth implementation can lead to the account takeover
Imagine a company account on a popular social media website and a third-party application that is used by the marketing department to publish news (e.g. an internal company application). When the attacker takes over the account he cannot find any sensitive company information because you do not post it on social media websites. What he can do is publish malicious posts and damage brand reputation.
What to do next? – Security Checklist ✅
The most important outcome of our series about the OAuth 2.0 security is to go through checklist of best practices for OAuth 2.0 – Feel welcomed to download it.
This is the first post of our series. In next posts we will focus on the potential consequences of insecure OAuth implementation and finally how to make it secure. If you want to be informed when they are out, subscribe to our newsletter below!