OAuth is a protocol that we use for delegated authorization. It may be easier to understand delegated authorization if we look at it in the context of contrast it with federated identity management (FIM), which we discussed last week. We use FIM so that users can authenticate with one company and then access the platforms of other companies within the federation. It establishes trusted relationships between separate organizations allowing them to share identities and authenticate users across domains. Delegated authorization is a little different in that it involves a user permitting one service to access their resources from another service on behalf of the user. With delegated authorization, you are basically saying “Hey Google, I give your permission to allow Slack to use documents in folder XYZ.”
One of the main benefits of OAuth’s delegated authorization is that it allows a lot of integration, automation and streamlining. As an example, by connecting Slack and Google via OAuth, you can simplify a lot of workloads and get more work done. OAuth is a popular protocol, so it can be used to integrate many popular services.
How does OAuth work?
The OAuth designers use the analogy of valet parking to describe how OAuth works. Some high-end cars have special keys that are used specifically for valet parking. These keys are different to the ones that the owner uses for driving the car around. Instead, the special valet keys can have specific limitations, such as a restriction on how far the car can be driven, or the inability to access the trunk.
The point of the valet key is that it gives access to the car, but limited access. It allows the owner the convenience of valet service, without having to worry about the car getting stolen and driven far away, or getting the trunk robbed.
OAuth works in much the same way. We often want the convenience of enabling one service to access another service so that they can integrate and automate our workloads–but we don’t want them to have full access. You might be totally fine with Slack accessing a specific work folder from Google Drive, but you probably don’t also want it to access the baby photos that are on Google Drive as well.
The important entities you need to understand in OAuth are the:
- Resource owner – This is the person who owns the data. In the example we described earlier, you would be the resource owner.
- Client – This is the application that is requesting access to data on the behalf of the resource owner. In the example, Slack would be the client.
- Authorization server – This server performs authentication on the resource owner. In the example, it’s Google’s login domain.
- Resource server – This is where the requested resources are hosted. In the example, it’s Google Drive’s API.
One of the interesting things about OAuth is that there are parameters such as scope that place specific limits on which data can be shared. If the resource owner only authorizes a scope of profile information to be shared, the profile information is the only information that the resource server can share with the client. The resource server may have a bunch of documents and photos as well, but unless these are included in the scope, they can’t be shared with the client over OAuth.
OAuth is an interesting but somewhat complicated protocol that enables a lot of our applications to work together on our behalf. It gives users more control over what and how they share data so that they can share the things they want, without having to share everything.
