Facebook OAuth 2.0 "code" and "token"

Question

Why do you need both a “code” and a “token” in the Facebook OAuth2 authentication stream, as described here: https://developers.facebook.com/docs/authentication/ ?

If you look at the OAuth dialog link ( https://developers.facebook.com/docs/reference/dialogs/oauth/ ), it seems like you only ever use a token to get user information, and if you specify the response_type parameter like token or code,token , then you will get the marker for the first time.

Why do you need to get a "code" and then use a code to get a "token", and not directly get a token?

I assume that I misunderstand what is happening with OAuth, but it seems that you completely avoid the https://graph.facebook.com/oauth/access_token request if you get the token in the dialog box for the first time.

Answer 1

Let's look at a simple example to differentiate an authentication code from an access token.

You, as a user, want to try out the new Facebook app called Highjack. So you click on the app and the Highjack app. will ask you to log in to your Facebook account. When you are done, Facebook generates an authentication code for you.

This code is then passed to the Highjack server, which uses its own FB client ID, FB secret, and your authentication code to obtain the access token.

In the above example, the authentication code confirms you because the user is a valid FB user. But the second step says: "you, as an FB user, get access to the Highjack application for certain resources."

If the Highjack application requires an implicit provision (for example, a direct access token), then the access token will be visible to you as well, as it is exchanged with the browser. This means that now you can call all Facebook APIs on behalf of Highjack using an access token. (You can only use the access token to get your personal information, but Facebook has no way of knowing who is calling their API.)

Since we have two sides (you and Highjack) that have authenticated with Facebook, we have this 2x mechanism.

Answer 2

Shamelessly taken from the Salesforce Documentation :

Authorization code

The authorization code is a short-term token representing a user access grant created by the authorization server and transmitted to the client application through a browser. The client application sends the authorization code to the authorization server to receive an access token and, optionally, an update token.

Access Token An access token is used by the client to execute authenticated requests on behalf of the end user. It has a longer service life than the authorization code, usually of the order of minutes or hours. When the access token expires, attempts to use it will fail, and a new access token must be obtained through the update token.

Answer 3

From OAuth 2.0 Spec :

The authorization code provides several important security benefits, such as the ability to authenticate the client, and transferring the access token directly to the client without transferring it to the user agent of the resource owner, potentially exposing it to others, including the resource owner.

So, basically - the main reason is to limit the number of participants receiving the access token.

The "token" is mainly responsible for clients that live in a browser (for example: a JavaScript client).

Answer 4

If you look at the OAuth type authorization code stream , then yes, there are two actuaries:

 1. <user_session_id, client_id> => authorization_code 2. <client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token 

In step 1: the user tells the OAuth server that "I want to authorize this client environment (client_id) to access my resource. Here is my authentication (user_session_id or whatever)"

In step 2: the client (client_id) tells the OAuth server that "I have a user authorization (authorization code), please give me an access token for future access. And this is my authentication (client_id & client_secret)"

You see, if we skip step 2, then there is no guarantee for client authentication. Any client can call step1 with a different client_id and get an access token for that client_id instead of its own. That is why we need step 2.

If you really want to combine step1 and step2, you can do something like this:

 <client_id, redirect_uri, client_secret> => access_token, refresh_token 

We use this approach in our Open Api platform, and so far have not found any security issues.

By the way, there is actually a type of implicit grant , that is:

 <client_id, redirect_uri> => access_token, refresh_token 

As a rule, it is applicable only to client applications that do not have a server part. In this case, the OAuth server must make sure that the redirect URI belongs to this client (for example, the same with the redirect_uri register)

Answer 5

The confusion occurred due to the fact that the user on his own behalf, and not the client application, is authenticated on the authorization server (for example, facebook). It is much easier to protect the client application (using https) and then the user agent (browser).

Here is the original wording from IETF-oauth ( http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4 ):

3.4. Authorization code

The authorization code is an intermediate result of the successful end-user authorization process and is used by the client to access and update the token. Authorization codes are sent to the client redirect URI instead of tokens for two purposes.

1. Browser-based streams provide protocol parameters to potential attackers through request URI parameters (HTTP referrer), browser cache, or log file entries and can be played. In order to reduce this threat, short-lived authorization codes are transmitted instead of tokens and exchanged for tokens is a more secure direct connection between the client and the authorization server.

2. Authenticate clients during a direct request between the client and the authorization server than in the context of the indirect authorization request. The latter would require digital signatures.

Answer 6

Answer) You need / need both a code and a token for added security.

According to Nate Barbettini, we want to take an additional step of exchanging the authentication code for the access token, because the authentication code can be used on the front channel (less secure), and the access token can be used on the back channel (more secure).

Thus, the security advantage is that the access token is not provided to the browser and therefore cannot be intercepted / received from the browser. We rely more on a web server that communicates via reverse channels. The access token, which is secret, may then remain on the web server and not be accessible to the browser (i.e. front channels).

For more information, watch this fantastic video:

OAuth 2.0 and OpenID Connect (in plain language) https://youtu.be/996OiexHze0?t=26m30s (Start 26 minutes)

Answer 7

Basically, as a Lix answer extension, the access code route allows the resource owner (i.e. Facebook user) to cancel authorization for their User Agent (i.e. their browser), for example, by logging out without canceling authorization for the offline client (i.e. e. of your application). If this is not important, then there is no need to use the access code route.

In addition, an access code is provided to ensure that the token provided to the server is actually registered to the Resource Owner (ie, the Facebook User), and not to the User Agent (or “The Man in the Middle”).

This is similar to the question of how to choose an implicit vs authorization authorization flow. Actually, here's what looks like the opposite point of view? .

In addition, as Drew noted ,

When the access token expires, attempts to use it will fail, and a new access token must be obtained through the update token.

the other part is the update token, but I don’t see it being explained too well in FB Docs. If I am right, the implicit grant (direct token) should be really short-lived, but it should be forced, and FB.js seems to hide a lot of this (I did not look so deep).

If I'm right, code%20token is an optimization that allows the user agent to have a token and allows the server to initiate the token exchange process in one request (since anything compared to Network IO is considered expensive, especially for the User Agent).

Answer 8

In theory,

• Access tokens cannot tell us if the user is authenticated and the authorization code is confirmed.
• The access code should not be used to gain access to the API, but there should be an access token.

If you have a one-page application or a mobile application without or with a minimal backend, your application may want to access the user's FB data directly through the web interface. Therefore, an access token is provided.

In another case, you may want the user to register / log into your application using some external authentication service provider such as Facebook, Google, etc. In this case, your web interface will send an authorization code to the server, which can be used to obtain an access token. from Facebook to the server side. Now your server is accessing the user FB data from the server.

Answer 9

This is due to the fact that the access token is provided to the AUTHENTIC client (third-party application) using a shared secret that only the FB and the client know. The only way a user could directly request an access token is to know a shared secret that will make it secret and can lead to a man in the middle attack. In addition, although the FB can guarantee a secure connection with the user, the FB cannot guarantee that the token transfer to the client is safe. However, FB (and OAuth2) requires a secure connection between the client and the FB. The access token is tied to the public client identifier (usually hashed), which means that only the original client application can use it to request the token, since the secret is sent along with the authorization code to obtain the access token.

Answer 10

In OAuth 2.0 with Facebook, the general concept is simple:

Step 1. Get the "Authorization Code" using a GET request

 request URI: https://www.facebook.com/dialog/oauth Params: response_type=code client_id={add your "App id" got by registering app} redirect_uri={add redirect uri defined at the registration of app} scope={add the scope needed in your app} Headers: None 

Step 2. Get the “access token” by sending the authorization code as a POST request

  URI: https://graph.facebook.com/oauth/access_token Params: grant_type=authorization_code client_id=<add your "App id" got by registering app> redirect_uri=<add redirect uri defined at the registration of app> code=<obtained authorization code from previous step> Headers: Authorization:Basic encode <App Id:App Secret> with base64 Content-Type:application/json 

Step 3. Use the access token obtained from the above step and get the user’s resources.

Answer 11

You get a token when a user logs in. But you can change the token when you perform other actions. EG as your application / page or publish as a user with offline_access .