In this article by Charles Bihis, the author of the book, Mastering OAuth 2.0, discusses the topic of gaining consent in OAuth 2.0.

OAuth 2.0 is a framework built around the concept of resources and permissions for protecting those resources. Central to this is the idea of gaining consent. Let's look at an example.

(For more resources related to this topic, see here.)

How does it work?

You have just downloaded the iPhone app GoodApp. After installing, GoodApp would like to suggest contacts for you to add by looking at your Facebook friends. Conceptually, the OAuth 2.0 workflow can be represented like this:

The following are the steps present in the OAuth 2.0 workflow:

1. You ask GoodApp to suggest you contacts.
2. GoodApp says, "Sure! But you'll have to authorize me first. Go here…"
3. GoodApp sends you to Facebook to log in and authorize GoodApp.
4. Facebook asks you directly for authorization to see if GoodApp can access your friend list on your behalf.
5. You say yes.
6. Facebook happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.

The preceding image and workflow presents a rough idea for how this interaction looks like using the OAuth 2.0 model. However, of particular interest to us now are steps 3-5. In these steps, the service provider, Facebook, is asking you, the user, whether or not you allow the client application, GoodApp, to perform a particular action. This is known as user consent.

User consent

When a client application wants to perform a particular action relating to you or resources you own, it must first ask you for permission. In this case, the client application, GoodApp, wants to access your friend list on the service provider, Facebook. In order for Facebook to allow this, they must ask you directly. This is where the user consent screen comes in. It is simply a page that you are presented with in your application that describes the permissions that are being requested of you by the client application along with an option to either allow or reject the request.

You may be familiar with these types of screens already if you've ever tried to access resources on one service from another service. For example, the following is an example of a user consent screen that is presented when you want to log into Pinterest using your Facebook credentials.

Incorporating this into our flow chart, we get a new image:

This flow chart includes the following steps:

1. You ask GoodApp to suggest you contacts.
2. GoodApp says, "Sure! But you'll have to authorize me first. Go here…"
3. GoodApp sends you to Facebook. Here, Facebook asks you directly for authorization for GoodApp to access your friend list on your behalf. It does this by presenting the user consent form which you can either accept or deny. Let's assume you accept.
4. Facebook happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.

When you accept the terms on the user consent screen, you have allowed GoodApp access to your Facebook friend list on your behalf. This is a concept known as delegated authority, and it is all accomplished by gaining consent.

Summary

In this article, we discussed the idea of gaining consent in OAuth 2.0, and how it works with the help of an example and flow charts.

Resources for Article:

Further resources on this subject:

• Oracle API Management Implementation 12c [article]
• Find Friends on Facebook [article]
• Core Ephesoft Features [article]