Download code from GitHub
OAuth 2.0 can be perceived as a protective layer for a given service, so that the client applications that are built for the service can have a standardized method of requesting the protected resources that belong to a user who uses the system, or resources that belong to the service in general. These resources may vary from various data that the user has stored, to various application programming interface (API) methods for system maintenance and more. The client applications, in order to obtain these protected resources, make HTTP requests to the predefined service endpoints and supply an access token— a token that says which user has approved the client application to access its data. OAuth 2.0 is a protocol that has found its place as an authorization framework in various services that are provided to clients, most commonly securing RESTful APIs and web-based applications. Additionally, when businesses want to communicate to other businesses purely by exchanging resources via services in a B2B manner, OAuth 2.0 can be used.
Tip
The OAuth 2.0 specification is fully named "The OAuth 2.0 Authorization Framework". It outlines the OAuth 2.0 protocol and leaves some points to be flexible and implemented in various ways; that's why it is important not to confuse it with a framework as in a technology stack; the term framework here means that the protocol can be implemented in various ways.
There are more cases, but what is evident is that OAuth 2.0 is able to handle the authorization layer in systems, providing access to protected resources in various scenarios, environments, and devices. Additionally, when it provides access, it does that on behalf of someone (most commonly the resource owner)—who is identified by the access token. But more details later.
More and more enterprises started using OAuth 1.0 and migrated to OAuth 2.0, from payment services such as PayPal and service providers such as Amazon to social media platforms, such as Facebook and Twitter, and various internal enterprise solutions. It's used in various scenarios, from securing service APIs to providing an easy-to-use sign-in mechanism and more. What we can notice is that OAuth 2.0 is found in enterprises in two ways: they use it and/or they support it. When enterprises consume protected resources from other service providers that are secured with OAuth 2.0, we say they use it (they may do the same internally between their own systems). Additionally, when enterprises secure their own services with OAuth 2.0 or provide OAuth-based solutions so that other enterprises can secure their services, we say they support it.
As the usage increased, developers ran into some common problems during the implementation phase, for both service providers and client applications. In OAuth 1.0, the use of cryptographic functions are a part of the protocol, which adds to the difficulty of the developers implementing it. Later on a security flaw was discovered, which had to be resolved, and resulted in a revised specification named OAuth 1.0a. Previous specifications also had a bad design decision. The use of Secure Sockets Layer (SSL) in order to secure data transfer between the parties that are part of the authorization flow was not mandatory, which meant sensitive information could be exposed.
Additionally, there were use cases that were not defined and could have been like the various authorization flows that are part of OAuth 2.0. It was evident that improvements could be made to the original OAuth 1.0 specification.
Development took off to define a new revised specification, versioned 2.0, authored by a bigger team and based on their experience in OAuth 1.0 implementations and deployments, on comments from the wider community, and on the additional OAuth 1.0 based specifications that were created meanwhile (and had the common goal of adding additional capabilities that were needed but not available in OAuth 1.0).
This resulted in the OAuth 2.0 authorization framework, delivering key improvements especially by simplifying and defining more clearly the way client developers should implement authorization against providers, in order to access protected resources.
Note
OAuth 2.0 is not backwards compatible with 1.0, as they don't share a lot of similarities in implementation details, and they differ in the structure of exchanged information.
Therefore, developers that have worked with OAuth 1.0 should not make assumptions about OAuth 2.0 without getting familiar with it in the first place. Implementations for both 1.0 and 2.0 can co-exist for a given provider if it is chosen to support both, due to legacy clients, for example.
Support from service providers is leaning towards OAuth 2.0. A rough estimate of the percentage between providers that support OAuth 2.0 compared to OAuth 1.0 shows that at least 60 percent are in favor of OAuth 2.0. Some exclusively support OAuth 2.0 (a notable example of this is Facebook with its Graph API), some support OAuth 2.0 and announced deprecation of OAuth 1.0 (for example, Google), and some service providers support both versions.
To have a glimpse into the benefits, without going technical (which is the point in the next chapters), several scenarios follow.
Imagine an enterprise providing an API for some customers (be it RESTful, SOAP-based, and so on). In order to make it secure and to have regulated access to it, one way is to use the so called basic authentication, where the username and password are sent using Base64 encoding—but not encoded or hashed—and SSL is used to secure the data transfer. The drawback here is that, in this type of authentication, the user, alongside his username, enters and sends his password over the wire as well.
What can be improved? In order to secure the API with OAuth 2.0, every time a request is made to the API, instead of username and password, an access token is sent. This token is obtained by the client application before making the requests, and represents the user on whose behalf the client application is using the API.
Related scenario—a client application, which is using the API, starts misbehaving and uses it improperly. All that has to be done is to revoke the access token, making all future requests invalid (if they are made with the same token).
Another important thing to note is that the access token can be set on how much access to have, which is called scope. So a client application may not have full API access when using access tokens. In contrast, if the client application was using username and password instead of access tokens, and these credentials were stolen, the whole API could be misused until the hijacked account is blocked.
Next, imagine a company utilizing a set of enterprise applications that are used internally. Company employees have to enter username and password manually in every separate application. This poses a security risk in several areas; there are several databases storing passwords, passwords are more often sent over, and so on.
With OAuth 2.0 what can be done is to have one application where the user logs in with his username and password (the OAuth 2.0 based service provider), and in all the other applications he is simply redirected to the provider where he logged in and confirms that he wants to be authorized. This way, instead of storing passwords these applications are storing the tokens for the users. The benefit is that when a password is stolen, the user has to reset his password, compared to when a token is stolen and it is revoked (invalidated).
Another related scenario is security in BYOD (bring your own device) companies. If a user brings his smartphone and uses an internal company application on it, and this smartphone gets stolen or compromised, the password of the user won't be exposed and only the tokens that were in use will have to be invalidated. The user can get a new device, and when he authorizes it he will get a new token.
Imagine that a user has an account on a photo sharing service, and also on a print ordering service.
If these two services have OAuth 2.0 integration between them, the user can authorize the printing service to access resources from the photo sharing service on his behalf. For example, the user would log in to the photo sharing service, then would log in to the printing service and request the integration, after which the user is redirected back to the photo sharing service, where he approves the authorization request.
From this point on, the printing service has an access token on behalf of this user, and can be aware which photos the user has uploaded. And the user can access the photos on the printing service without re-uploading them again there, but retrieved via the photo sharing service.
The best part of it is that the user hasn't given the username and password combination to the printing service, but instead the printing service has received an access token when it was authorized by the user.
This shows one of the key strengths of using OAuth 2.0—authorization delegation. With OAuth 2.0 you can give access to your data/resources on some service to another one, and easily revoke this access when you change your mind. This applies everywhere, from internal enterprise applications to various services such as social media applications.
Another key strength of OAuth 2.0 is federated identity.
With federated identity, a person's digital identity and details (such as e-mail, name and surname, and gender) can be linked between several distinct services.
The previous two examples show this, but let's see another example; users can log in to one OAuth 2.0 provider (for example, Facebook or LinkedIn) and then log into other web services via this provider, without entering new username and password. For example, a user wants to leave a comment on some blog post and needs to be identified in order for the comment to be accepted.
This case is also known as using OAuth 2.0 for authentication. The client application (for example, the blogging platform) is requesting only the user's information after it got authorized and nothing more.
