An Introduction to OAuth 2.0 | CyberNcrypt

You’ve almost certainly come across websites that allow you to log in using your social media account while browsing the web. This feature is most likely built with the popular OAuth 2.0 framework. OAuth 2.0 is appealing to attackers because it is both extremely common and prone to implementation errors. This can lead to a number of vulnerabilities, giving attackers access to sensitive user data and potentially bypassing authentication entirely.

Introduction

OAuth 2.0 is an authorization framework that allows apps like Facebook, GitHub, and DigitalOcean to gain limited access to user accounts on HTTP services. It works by delegating user authentication to the service hosting the user account and granting third-party applications access to that user account. OAuth 2 provides authorization flows for web, desktop, and mobile applications.

Importantly, OAuth enables the user to grant this access without revealing their login credentials to the requesting application. This means that users can choose which data they want to share rather than handing over complete control of their account to a third party.

How does OAuth 2.0 function?

OAuth 2.0 was originally designed to allow applications to share access to specific data. It functions by defining a set of interactions between three distinct parties: a client application, a resource owner, and the OAuth service provider.

• Resource Owner – The resource owner is the user who grants an application access to their account. The scope of the authorization granted limits the application’s access to the user’s account (e.g. read or write access)
• Client – The client is the application that wishes to gain access to the user’s account. Before it can do so, the user must authorize it, and the authorization must be validated by the API.
• Resource Server – The resource server is where the protected user accounts are kept.
• Authorization Server – The authorization server verifies the user’s identity and then issues access tokens to the application.

The actual OAuth process can be implemented in a number of different ways. These are referred to as OAuth “flows” or “grant types.” We’ll concentrate on the “authorization code” and “implicit” grant types in this topic because they’re by far the most common. In general, both of these grant types entail the following stages:

• The application asks the user for permission to access service resources.
• The application receives an authorization grant if the user authorized the request.
• By presenting authentication of its own identity and the authorization grant, the application requests an access token from the authorization server (API).
• The authorization server (API) issues an access token to the application if the application identity is authenticated and the authorization grant is valid. The authorization process is finished.
• The application requests the resource from the resource server (API) and authenticates using the access token.
• The resource server (API) serves the resource to the application if the access token is valid.

The actual flow of this process will vary depending on the type of authorization grant in use, but this is a general idea.