Homework 5: Twitter and Facebook Authentication

Consumer Key- This is a key that identifies your application when making requests to twitter. It is unique to your application. It is used in combination with the consumer secret to authenticate. This is unlike a username for a twitter account in that it identifies the app, not a user. 

Consumer Secret- The consumer secret would then be like a password for the application to go along with the consumer key. Both the consumer key and this are used to authenticate the twitter application to twitter. Each app has a unique key and secret.

Access token- This identifies the user (like a username) using the application to authenticate with twitter through the application. It “allows the server and the resource owner greater control and flexibility in granting client access”.

Access Token Secret- This is like the password for the user using an application. It allows a user to sign in through an app without their actual credentials ever becoming visible to the app owner or anyone in between.

All 4 of these are required to build an application that allows a user to sign in to twitter and do things with their actual account such as, post a tweet, send or receive direct messages, and retweet tweets. Without this OAuth structure, it would not be possible for a user to securely log in through a 3^rd party application safely and securely.

How to obtain an access token by using the authorization flow:

Sign in with twitter-

1.       First, your application must get a request token by sending a signed message to POST oauth/request_token.

2.       Then, the user must be directed to twitter so they can complete the appropriate flow.

a.       The user must be directed to GET oauth/authenticate, and the request token obtained in step 1 should be passed as the oauth_token parameter.

3.       To render the request token into a usable access token, your application must make a request to the POST oauth/access_token endpoint, containing the oauth_verifier value obtained in step 2.

4.       Once this is all completed, a successful response will contain the oauth_token, oauth_token_secret, user_id, and screen_name parameters. The token and token secret should be stored and used for future authenticated requests to the Twitter API.

 

Below is an example of what an approved response will look like:

HTTP/1.1 200 OK

Date: Thu, 13 Oct 2011 00:57:08 GMT

Status: 200 OK

Content-Type: text/html; charset=utf-8

Content-Length: 157

Pragma: no-cache

Expires: Tue, 31 Mar 1981 05:00:00 GMT

Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0

Vary: Accept-Encoding

Server: tfe

oauth_token=7588892-kagSNqWge8gB1WwE3plnFsJHAZVfxWD7Vb57p0b4&

oauth_token_secret=PbKfYqSryyeKDWz4ebtY3o5ogNLG11WJuZBc9fQrQo

Information taken from here.

PIN-based Authorization-

The PIN-based flow is implemented in the same exact way as Implementing Sign in with Twitter and 3-legged authorization, with the only difference being that the value for oauth_callback must be set to oob during the POST oauth/request_token call.

Go through the steps above and be sure that the oauth_callback is set to oob during the POST oauth/request_token call.

Information taken from here.

Three Legged Authorization-

This flow is almost identical to the flow described in Implementing Sign in with Twitter, with two exceptions:

•  The GET oauth/authorize endpoint is used instead of /oauth/authenticate
• The user will always be prompted to authorize access to your application, even if access was previously granted.

Go through the original steps above and make these changes to implement the three legged authorization version.

This information taken from here.

Facebook Access Tokens:

User- The user access token is the standard token for API calls. These are generated when a user approves access for an application on Facebook. It allows the app to do things like reading, publishing and deleting posts, comments, or messages on behalf of the user. By default they have a short validity period but that can be exchanged with ones that last longer. These tokens are unique to each user and each app.

Page- Page tokens are used to manage Facebook pages. They act the same way as the user token, giving the app the ability to read, publish and delete posts, comments, or messages but rather than it being for an individual user, it is for pages. Such as Bands, artists, or any other type of page. Page access tokens are unique to each Page, admin and app.

App- This app token, unlike the other two, requires a different login flow but it still can be done in code. This token would be used for modifying app settings, creating and managing test users or reading App Insights data. Like the user token, the app token will also allow the app to publish posts on behalf of the user if it has the publish_actions permission assigned. It can also publish a status update on their behalf. App tokens do not expire unless the App Secret is reset. App access tokens are unique to each app.

Facebook App Secret and App Access Token:

The app secret is used to generate access tokens and also secure the usage of the app to only those who are trusted. The secret can be used to generate an app access token which allows the app to make API requests on behalf of any user or the app. Because of this it is important that this is kept secure and not compromised. 

Logging in as an app only allows the user to control the users account while logging in in an app allows both control over the users account and control over the app account. Though if logged into the app, the user needs to give the app permission to post or have access to other aspects of the account. User tokens expire while app tokens do not. App tokens can be reset.  

Information taken from here.