Facebook docs:
Facebook Platform supports two different OAuth 2.0 flows for user login: server-side (known as the authentication code flow in the specification) and client-side (known as the implicit flow). The server-side flow is used whenever you need to call the Graph API from your web server. The client-side flow is used when you need to make calls to the Graph API from a client, such as JavaScript running in a Web browser or from a native mobile or desktop app.
What is the difference between access tokens taken by these flows?
It seems like they length differ.
Can we use server-side flow token on a client? And otherwise, can we use client-side flow token on a server?
Currently, Facebook says this about access_tokens. On Server-side OAuth
if the access_token is generated from a server-side OAuth call, the
resulting access_token will have the longer expiration time by
default. If the call is made while there is still a valid long-lived
user access_token for that user, the returned user access_token from
this second call may be the same or may have changed, but in either
case the expiration time will be set to a long expiration time.
Where as client-side OAuth flow will give you a existing, non-expired, short-lived user access_token. To make this access_token long lived, facebook is providing a new endpoint that exchanges the short lived access_token with an access_token with longer life. The endpoint is
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
Also please note that
Currently the long-lived user access_token will be valid for 60 days
while the short-lived user access_tokens are currently valid from 1 to
2 hours.
Excerpt from https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal/
For those that like me are facing the same issue in 2014, Facebook improved the documentation on access tokens.
Tokens are Portable
One important aspect to understand about access token is that they are portable. Once you have an access token you can use it to make calls from a mobile client, a web browser, or from your server to Facebook's servers. If a token is obtained on a client, you can ship that token back to your server and use it in server-to-server calls. If a token is obtained via a server call, you can also ship that token down to a client and then make the calls from the client.
(from https://developers.facebook.com/docs/facebook-login/access-tokens/#portabletokens)
So yes, you can use access tokens from the client on the server and vice-versa; as already stated by naveen, the difference is that client-obtained tokes are short lived, whilst server ones are long lived. You can also convert a short-lived token to a long-lived token by following the directions here: https://developers.facebook.com/docs/facebook-login/access-tokens/#extending
Token can be used to make API calls since it represented that you are authenticated and authorized to do something.
Code can not be used directly to make any API call. It must be first redeemed with your app secret to get a token.
In other words, code is like an encrypted token that only parties with app secret can decrypt it.
BTW, your app secret should only appears in your server code, never in mobile or web client.
The video basically explains all this at around 13:00
https://developers.facebook.com/docs/facebook-login/security
A user access token (and page access token) will be the same in either server-side or client-side environment (other than maybe for the time stamp expiration).
An app access token will be exactly the same either server-side or client-side.
Related
I'm just looking at migrating an existing Login with Facebook flow over to Sign in with Apple with the hope of eliminating FB Login entirely from our iOS app.
The client side seems straight forward enough, however there's one topic I can't seem to see any documentation or discussion on Stack Overflow about - a Sign In with Apple equivalent for FB App Access Tokens.
Facebook Login supports different token types (https://developers.facebook.com/docs/facebook-login/access-tokens/) and currently our app back end supports 2 authentication flows.
From End App Users, they Login with Facebook, send the provided client User Access Token to the app backend which validates the token against Facebook and then issues an app specific JWT token to the app client that is used in further app API calls until expiry.
From backend server components. These request an App Access Token from Facebook e.g.
curl -X GET "https://graph.facebook.com/oauth/access_token
?client_id={your-app-id}
&client_secret={your-app-secret}
&grant_type=client_credentials"
The App Access Token is then send to the app backend which validates the token against Facebook and then issue an app specific JWT token that is used in further server to server API calls until expiry.
Replacing 1 above seems straightforward but what about 2? Is there a mechanism for achieving the same flow with Sign In with Apple?
It seems like the https://developer.apple.com/documentation/signinwithapplerestapi would be the API to use for validation but is there a way to generate an App Access Token equivalent for Sign In with Apple in the first place to validate using this REST API?
Thanks
I think it's possible
I'm not exactly sure how to really use it or validate it yet, but you get an access_token in the response from https://appleid.apple.com/auth/token when Generating and Validating Tokens
Getting an access_token from Apple
This example assumes you have an Authorization Grant Code, but the same is possible if you have a refresh_token, etc. instead.
Prepare a POST request to https://appleid.apple.com/auth/token
Fill out the following key-values as x-www-form-urlencoded:
client_id
client_secret
code
grant_type
redirect_uri
If successfull, this will return:
**access_token**
token_type
expires_in
id_token
I'm not sure if this is the type of access_token you're looking for, but I wanted to bring it to your attention.
It may be useless for now
After writing this, I came across this thread in the forums where Apple said:
Currently, the access token only indicates a successful refresh token validation. There are currently no endpoints where it can be used and it is reserved for future use. So, it can be ignored for now.
I am building an application that does not have a client interface.
At the setup step: The user logs into the server throught a browser once using oauth, and the server makes sure that the client is identified.
From this point on, no browsers are invlovled. It all happens in the background.
It then keeps acting on behalf of the user for as long as the user can be validated.
That means that once in a while, my server needs to call the oauth provider to validate the user still exists.
Until now, I have only used google oauth: Once in a while, I would call the refreshtoken api, and get a new token indefinitely from the server side. (you need to ask for "offline access" when you get the user token).
Now I would like to use facebook as well, but reading their APIs, I see no mention of a possibility for a server to refresh it's tokens:
https://developers.facebook.com/docs/facebook-login/access-tokens/refreshing/
It looks like it all has to be done from the client device.
As I have no client device, does this mean that I cannot write this sort of app with facebook?
I think your scenario can be covered through Facebook's mechanism. But you need to support a re-login if some error occur while using long lived access token. This can happen due to security measure taken by Facebook (ex:- data breach, cryptographic breach) or when user revoke tokens or change password or when tokens are not used for a longer time.
Steps to follow (According to their docs),
Obtain a User access token
These are short lived
Short-lived tokens usually have a lifetime of about an hour or two
Exchanging Short-Lived Tokens for Long-Lived Tokens
These have life span of around 60 days, even when they are not used.
long-lived token generally lasts about 60 days.
Basically, once you obtain a long lived token, you can use it from the server application. During this process, you required a client which used browser only to obtain short lived access token.
But as previously mentioned, these tokens can expire,
These tokens are refreshed once per day, when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.
So you will require to obtain new ones by going through above two steps.
I'm using the URL below to get the auth token:
https://www.facebook.com/dialog/oauth?client_id=CLIENT_ID&redirect_uri=RETURN_URL&scope=manage_pages,publish_stream
This page will redirect to another URL with the code token in query string. I'm using this code token to get the Page access token automatically and publish to the Page 'offline'.
In recent days, it seems that Facebook has changed the expiration time of this token code.
I am able to use this token once. The time expiration is very short. Anyone know if there really was a change in facebook? Is there any other alternative to work with this?
This was part of the December 5th changes on the Roadmap: the code can only be exchanged for an access_token once and must be exchanged within 10 minutes of generation.
New security restrictions for OAuth authorization codes We will only
allow authorization codes to be exchanged for access tokens once and
will require that they be exchanged for an access token within 10
minutes of their creation. This is in line with the OAuth 2.0 Spec
which from the start has stated that "authorization codes MUST be
short lived and single use". For more information, check out our
Authentication documentation.
If you're unsure how to log users in correctly because you were relying on the old, incorrect behaviour, ensure you're using the newest SDKs and read the Login documentation in detail, specifically the Server Side Login documentation which shows how to exchange the code for a token
Once you have the token, save it using whatever session storage mechanism your app uses (PHP SDK will store it in a PHP session for you) and use the access token on subsequent calls instead of trying to obtain a new access_token from the code
How to extend life time of google account access token i used gwt-oauth2-0.2 to obtain an access token but problem is that it expires very soon .i want to get a token with extended life time preferably that does not expires.
Since this is GWT code, it's executed in the client using client-side JavaScript. It is not possible to get a long-lived access token from within client-side JavaScript. The issued tokens last 60 minutes currently-- and you can always get another token later without any user interaction (as the user has already approved the OAuth grant request). This should be sufficient for all client-side access to a user's data.
If you're comfortable using server-side code instead, you could use the OAuth 2.0 flow for server-side web applications, and specify access_type=offline. This gives you an authorization code passed as a query parameter-- you then make a server-to-server call to exchange the authorization code for an access token. The first time you exchange a code for a given user, you'll also get a refresh token. Although the access token will expire, the refresh token can be used indefinitely to obtain new access tokens for that user by simply making a server-to-server call.
While reading Facebook's post regarding offline_access permission removal, I was thoroughly confused by their reference to short-lived and long-lived access tokens.
This page mentioned
The duration for which a given access token is valid depends on how it
was generated
But I failed to find any further information.
Anyone has insights on how this determination process works in detail?
The access token your app gets for a Client-Side authentication is short lived (about 2 hours), but you can extend it and get a long lived token using the new endpoint with a valid access token.
In the Handling Invalid/Expired Access Tokens it says under Desktop Web and Mobile Web apps which implement authentication with the Javascript SDK:
Calling FB.getLoginStatus() or ensuring status: true is set when you
call FB.init() means that the next time a user lands on your
application and is signed into Facebook, the authResponse object you
are passed as a result of those calls will contain a fresh, valid
access token.
In this case, its simply the act of the user using your application
which implicitly generates a new access token.
If you use the Server-Side authentication flow then you will automatically get a long lived token (about 60 days) automatically.
When that expires you have to send the user to re-authenticate in the same flow (code exchanging).
You can of course use both methods and that way you can get a long lived token in the server and a short lived token in the client.