First look at the server-side flow

Imagine now that the GoodApp application is no longer a simple HTML/JavaScript web application, but is now a full 3-tier client-server-database application. This client application is now able to securely store confidential information thanks to the server and database layer, and so is a perfect candidate for the authorization code grant workflow.

A trusted client – GoodApp requests access for user's Facebook friends using authorization code grant

Remember that a trusted client is able to securely store confidential information, such as client credentials. So, during the registration process (which we will discuss in Chapter 3, Four Easy Steps), trusted clients will be issued credentials to store. Here is what that exchange looks like with a registered, trusted client using the authorization code grant flow, once again, 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 server (not the client web application) a tag that can be exchanged for a key that can access your Facebook friend list. Notice that Facebook this time gives a tag and not a key. Also notice that Facebook issues this to the server of GoodApp, not the client web application.
5. GoodApp makes a request to Facebook to exchange the tag for a valid key to access your Facebook friend list on your behalf.
6. Facebook validates this tag, and upon successful validation happily obliges, giving the GoodApp server the requested key.
7. The GoodApp server then makes another request to Facebook, this time for your friend list, presenting with it the key that it just received.
8. Facebook validates this key, and upon successful validation happily obliges, giving GoodApp your friend list.
9. GoodApp then uses this information to tailor suggested contacts for you.

Once the user authorizes GoodApp to access their Facebook friends on their behalf, Facebook sends GoodApp a tag. This tag is then exchanged for a key. This key will have the permission to fetch your friend list.

One important note about this exchange is that the tag used in the preceding workflow can only be exchanged for a key once. After it has been used once, it can no longer be reused to fetch another key. The tag is a one-time-use tag, and so is said to be consumable.

Tip

A tag is "consumable"?

This can be thought of like a coat-check tag, where it can be presented to the coat-check attendant and in exchange, you get your coat. If you present the tag again, they will look and see that your coat has already been claimed, and you get nothing.

In OAuth 2.0 terminology, this tag is known as an authorization code and it can be exchanged for an access token, which can subsequently be used to request access to the protected resource. After exchanging this authorization code for a token, the workflow is identical to that of the implicit grant type flow: GoodApp requests the user's friend list from Facebook, presenting with it the key (access token). Facebook validates the key and returns to GoodApp the user's friend list as requested.

The important distinction between this flow and the untrusted flow (that is, implicit grant flow) is that the access token is never sent to the browser! The access token is exchanged directly between Facebook and the GoodApp server, so the access token never gets sent to the GoodApp browser application. Because of this, the access token has significantly less chance of being leaked or intercepted.

The big picture

Here is the entire interaction between the user, GoodApp, and Facebook, now within context:

This workflow 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 server (not the client web application) a tag that can be exchanged for a key that can access your Facebook friend list. Notice that Facebook this time gives a tag and not a key. Also, notice that Facebook issues this to the server of GoodApp, not the client web application.
5. GoodApp makes a request to Facebook to exchange the tag for a valid key to access your Facebook friend list on your behalf.
6. Facebook validates this tag, and upon successful validation happily obliges, giving the GoodApp server the requested key.
7. The GoodApp server then makes another request to Facebook for your friend list, presenting with it the key that it just received.
8. Facebook validates this key, and upon successful validation happily obliges, giving GoodApp your friend list.
9. GoodApp then uses this information to tailor suggested contacts for you.

When should this be used?

The authorization code grant type flow was designed for trusted clients, and so should be used for any client applications that have the ability to securely store and transmit information. These clients are typically client-server-based applications. However, depending on the platform, and the design of the application itself, native mobile applications can also be considered trusted as well.

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

• Client/server application where the client is an HTML/JavaScript application backed by a .NET backend attached to a SQL Server database
• A native iPhone application that is powered by a server-based backend that it communicates with
• Client/server application where the client is an Android application and the backend is a Java server with a Bigtable persistence layer

Pros and cons of being a trusted client

As you can imagine, there are many advantages as well as disadvantages of being a trusted client. Here are some of the main points (notice the contrast of pros and cons as compared to an untrusted client):

Pros

There are two main advantages of being a trusted client:

• More security: The key is shared only between the service provider and server-side of the client application. It never gets sent to the browser, and so has much less of a chance of being intercepted.
• Long-term and offline access: Because the client is able to securely store information, they can store the keys and properties necessary for long-term, and even offline, access to a user's data.

Cons

Unfortunately, there is a disadvantage associated with this:

• More complexity: To achieve the added security features that make this workflow so beneficial, a more complex infrastructure must be in place to facilitate the more complex key exchange that this workflow utilizes