OAuth 2.0 (Open Authorization) is a standard for authorization where a user allows an application to access their resources hosted on another application, on their behalf, without the sharing of their credentials. It’s a delegated protocol, meaning that someone who controls a resource allows a software application to access that resource with their permission. In the OAuth 2.0 authorization flow, user credentials are never shared. Instead, an access token is granted and used to prove the identity.
A common example would be a user logging into an app or website using their existing credentials from another service such as Facebook or Google. The app or website doesn’t care about the user’s credentials, but just wants to know that the user is the same and has successfully logged into that service provider.
Let’s use a fictitious scenario to help explain the OAuth 2.0 authorization flow.
Let’s say a user named John is using a money management application that helps him keep track of his spending across multiple accounts. Within this application, John wants to grant it access to pull his transaction history from one of his banks. Instead of John having to share his username and password with the application, it can instead use the OAuth 2.0 standard to access his user data by way of an access token. John simply needs to log into the service provider (the bank) and grant the application permission to access the bank account. An access token will be granted and used to pull the transaction history.
The OAuth 2.0 authorization framework consists of four different core roles. Let’s look at them within the context of John’s situation:
Now that we have the scenario in place and have described the four roles involved, let’s see how the OAuth flow works:
OAuth 2.0 has a number of different types of authorization grants used for different scenarios and technology. The example flow above is called the Authorization Code grant and is best for server-side apps as the access token and user data isn’t sent via the browser. This is the one of the most commonly used grant types. For an overview of the other grants, take a look at our more detailed post on our blog.
OAuth 2.0 is noted to be a complete rewrite of OAuth 1.0 and is not backwards compatible. They are best thought of as two completely different protocols. OAuth 2.0, released in 2012 two years after the release of OAuth 1.0, improves significantly in that access tokens can contain an expiration time as well as refresh tokens, there is reduced complexity in generating signatures, and having more defined roles and non-browser support. OAuth 2.0 offers more flexibility and is seen as the superior protocol of the two.