APP_ID

APP_SECRET

ACCESS_TOKEN

Access token (short-lived or long-lived) obtained through Authorization Flow

POST_ID

TIMESTAMP

INPUT_TOKEN

Access token (short-lived or long-lived) associated with YOU, the Facebook App owner

OWNER_ACCESS_TOKEN

Owner's access token (short-lived or long-lived) obtained

CREATED_TIME

Facebook’s Graph API is the central means for programmatic access to Facebook data.  It is the entry point for reading and writing to Facebook’s “social graph”. 

This course begins with a discussion of the major concepts of the Facebook Graph API. You will learn basic concepts like authentication, authorization, and access tokens. Then, you will build out your mini-project step by step by deploying the "Login with Facebook"  web page. By the end, you will have a thorough understanding of how to build API integrations in your own projects.

Facebook Login and the Facebook Graph API

# The typical OAuth2 flow

The "Login with Facebook" flow runs very much according to the OAuth2 protocol, proceeding as you would expect. If you are not familiar with OAuth2, we will walk through an example here to illustrate how the "Login with Facebook" flow works. By the end of this lesson, you will be equipped to navigate OAuth2 flows not only for Facebook but also for other providers including:

* Google
* Twitter
* GitHub
* StackExchange

Previously we talked about the difference between _authentication_ and _authorization_. Recall that _authentication_ is the verification of a user's _identity_, while _authorization_ is that user giving permission to access their resources. This all comes into play when we talk about OAuth2 and Facebook Login.

# Owners, resources, servers, and clients

In the OAuth2 world, any piece of data is a **resource**. A user's name, email address, most recently liked post, list of friends &mdash; each of these are resources. The **resource owner** is the user.

Facebook users _own_ their data, so that means Facebook users are the **resource owners** of their Facebook data. Because Facebook data (resources) resides on a Facebook server, that server is called the **resource server**.

A **client** is a third-party application that is requesting access to resources that it does not own. To do this, it needs the resource owner to authorize the client to access those resources. The negotiation of this permission happens through the **authorization server**.

In many cases, the resource server and the authorization server are one and the same. This is the case for Facebook, where requests for authorization _and_ requests for resources are both directed to `graph.facebook.com`.

# A walk-through of the flow

To make this more concrete, let's consider an example. Let's assume that we have a web application (the _client_) named Taco Inspirations. Users of Taco Inspirations allow the application, every Tuesday at noon, to write a Facebook post on their behalf with a taco-themed inspirational quote. Yes... this is a ridiculous web application. But it will work for our example.

Learn the authorization flow of "Login with Facebook" in detail.

__default

Understanding the "Login with Facebook" Authorization Flow

The typical OAuth2 flow

Owners, resources, servers, and clients