What problems does it solve?
Have you ever logged into a site using your Google account? Have you ever posted to Pinterest and Instagram at the same time? Have you ever shared a link to your wall from any application other than Facebook? These are all examples of OAuth 2.0 in use!
At a high level, the OAuth 2.0 protocol allows two parties to exchange information securely and reliably. In more practical terms, you'll find that the most common uses of OAuth 2.0 involve two things:
- Allowing a user to log into an application with another account. For example, Pinterest allowing users to log in with their Twitter accounts. This is known as federated identity.
- Allowing one service to access resources on another service on behalf of the user. For example, Adobe accessing your Facebook photos on your behalf. This is known as delegated authority.
Both of these combine to allow the creation of powerful applications that can all integrate with each other.
Tip
Both of the scenarios mentioned in the preceding list are actually really the same scenario. In both, the user is accessing a protected resource on behalf of another party. In the first example, the protected resource is the user's account information, while in the second example the protected resource is the user's Facebook photos. This will become clearer as we explore the details of how the OAuth 2.0 protocol handles these situations.
Federated identity
Federated identity is an important concept in identity management. It refers to the concept that allows one service provider to allow authentication of a user using their identity with another service provider. For instance, imagine a user that logs into Foursquare and Amazon with their Facebook credentials. In this example, the user only needs to maintain a single user account, their Facebook account, which gives them access to several service providers; in this case, Facebook itself, plus Foursquare, and Amazon. They don't need to create individual accounts on Foursquare or Amazon, and therefore, don't need to maintain three separate passwords. In this sense, the user's identities across these sites are federated, as in, they are made to act as one.
Tip
The OAuth 2.0 Authorization Framework
Strictly speaking, the OAuth 2.0 protocol is actually an authorization protocol and not an authentication protocol. Because of this, OAuth 2.0 alone cannot provide federated identity. However, when used in a certain way, and in conjunction with other protocols, OAuth 2.0 can provide federated authentication, which is a key component to federated identity systems.
See the OpenID Connect section in Chapter 12, Extensions to OAuth 2.0, to see how the OAuth 2.0 protocol can be combined with OpenID to provide an authentication layer on top of the authorization framework described by the OAuth 2.0 specification.
Delegated authority
Delegated authority is another important concept in the identity space. It refers to the ability for a service or application to gain access to a user's resources on their behalf. Take, for instance, LinkedIn, which can suggest contacts for you to add by looking at your Google contact list. In this example, LinkedIn will be able to view your Google contact list on your behalf. Permission to access your Google contacts has been delegated to LinkedIn.
Real-life examples of OAuth 2.0 in action
Now that we understand the basic principles of OAuth 2.0, let's take a look at some everyday, real-life examples of OAuth 2.0 in action:
- StackOverflow allowing you to log in with your Google account
- Posting a status update from your phone using the Facebook mobile application
- LinkedIn suggesting contacts for you to add by looking at your Google contacts
- Pinterest allowing you to pin something from a WordPress blog
- Sharing an article to your Facebook feed from the article itself
As you can see, if you've ever done any of these things, or anything similar, you have probably already used OAuth 2.0.
