First look at the client-side flow

Let's, once again, go back to our example of GoodApp wanting to suggest contacts to you by looking at your Facebook friends. Imagine that the GoodApp client application is actually a simple web application hosted in the browser. This is an example of an untrusted client due to its inability to securely store information. The implicit grant type is best suited for this type of client application. Let's look at how the exchange of information (step 4 in the workflow image mentioned in the User consent section) is achieved using the implicit grant type.

An untrusted client – GoodApp requests access for user's Facebook friends using implicit grant

Since GoodApp, in this case, is an untrusted client, they cannot be trusted to store or relay any confidential information. Specifically, they cannot store any client credentials or tokens. Because of this, they have a very simple workflow. Here is what the exchange looks like, picking up after GoodApp directs you to Facebook for user consent:

Here are the steps performed in the preceding flow chart, picking up from step 3:

1. …
2. …
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 then gives the GoodApp client application (in this case, an HTML/JS web application running in a browser) a key that can be used to access your Facebook friend list. Notice that Facebook doesn't actually give the GoodApp web application the friend list itself.
5. The GoodApp web application then makes a request to Facebook for your friend list, presenting with it the key that it just received.
6. Facebook validates this key, and upon successful validation happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.

Once you have authorized GoodApp to access your Facebook friends on your behalf, Facebook sends GoodApp a key, which it can use to access your friend list. In OAuth 2.0 terminology, this key is appropriately called an access token. This token represents the access that is being granted for GoodApp to access your friend list on your behalf.

Simply, this access token can be thought of as a key. This key only works on certain doors. In this case, this key has the ability to access your friend list, and nothing more. GoodApp cannot access anything else with your account, nor can they access the friend list of any other user with this key.

Note

Access token versus bearer token

An access token is a string value that represents the access you have to a protected resource for a particular amount of time. You may also hear reference to something called a bearer token. A bearer token is simply a type of access token. There are other types of access tokens, but bearer is the most commonly used token type.

It is known as a "bearer" token because the bearer of the token holds all that is necessary to use it. No additional information is required. What this translates to is, anyone who has this bearer token, say GoodApp, will be able to use it and Facebook will happily return your friend list, no questions asked. What this also means is that if GoodApp happens to leak this token and it finds itself in the hands of a malicious user, they will also be able to use it to get your friend list.

This is very similar to a physical key: the key always unlocks the lock, no matter who is holding it.

Now that GoodApp has this key, it makes a request to Facebook to access your friend list, presenting with it the key that they just received. Facebook validates the key and returns your friend list to GoodApp, as requested. GoodApp can now craft their contact suggestions for you. Done!

The big picture

Here is the entire interaction between the user, GoodApp, and Facebook, using the implicit grant type, now within context:

This interaction is repeated every time GoodApp wants, or needs, to access some protected resources on behalf of the user. It can be summarized in full with these 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 then gives the GoodApp client application (in this case, an HTML/JS web application running in a browser) a key that can be used to access your Facebook friend list. Notice that Facebook doesn't actually give the GoodApp web application the friend list itself.
5. The GoodApp web application then makes a request to Facebook for your friend list, presenting with it the key that it just received.
6. Facebook validates this key, and upon successful validation happily obliges, giving GoodApp your friend list. GoodApp then uses this information to tailor suggested contacts for you.

When should this be used?

The implicit grant type was designed for untrusted clients, and so it should be used accordingly. These clients tend to be pure browser-based applications, such as HTML/JavaScript applications, or Flash applications, which do not require long-term access to the user's data.

Here are some examples of client applications that should use the client-side flow:

• An HTML/JavaScript application running in Safari on an iPhone
• A Flash application running in Chrome on an Android device
• A native iOS application that operates without a backend server
• An HTML/JavaScript application running in Firefox on the desktop

Pros and cons of being an untrusted client

As you can imagine, there are many advantages as well as disadvantages of being an untrusted client.

Pros

There is a convenient pro for being an untrusted client:

• Simplicity: Due to the straightforward design, this solution is very simple to implement. Since all of the work happens in the browser, no backend servers or data stores are required for such an application. (If they had these, they could be considered trusted.)

Cons

However, here are the cons:

• Less security: The key must be relayed to the browser for the client application to use. The browser is considered public and so this key may easily fall into the hands of another user.
• Short-term access only: Since the client is untrusted, they cannot store keys for long-term use. Because of this, the user will have to reauthenticate and regrant access more often than with a trusted client.

Tip

Best practice

As an application developer, if you are developing an application on an untrusted client using the implicit grant type, it is best to restrict your requests to read-only permissions. That way, if anyone were to steal the user's key, they would only be able to read the user's data, not modify it. The data may still be confidential, but at least you are minimizing the potential damage that may occur in the case of a leak.