Using app tokens instead of user/page tokens in Facebook Graph API - facebook-graph-api

Facebook's Graph API returns 3 types of tokens: User tokens, Page tokens, and App tokens. Our web app uses User and Page tokens to read and publish data to users and pages respectively. It works great except for the fact that the 60-day token lifetime requires repeated re-auths...
I then noticed this article on App tokens, which mentions that a) they don't expire and b) they allow you to publish on behalf of users
I also tried some reading private stream data off both user and page objects with the App token, and that worked as well. So what's the deal? Can I just use the App token on all my calls instead of the User/Page generated tokens, and not ever have worry about expirations?

The App token authenticates your app to Facebook as the application itself. This is fine for public data, but if you have users logging in, it's probably not what you want.
If you want to take actions on behalf of your users, you will still have to have them authenticate and use their user and page access tokens.

Related

API: How to secure access from non-related users?

I am developing a REST API. In my mobile application we have multiple user roles, they all use the same API. Think the roles are like customer, supplier, and admin. The API is using tokens, making sure everyone need to be logged in and should send the token to the API.
However, if someone has the token somehow, he can easily any information belong to any user. For an example, using the token of customer A, we can view the information of customer B, C` and so on.
Not only that, we can also access the API calls dedicated for the admins using the above mentioned token.
this is what I thought of doing.
Send the user ID with every request. Also embed the user ID into the token. In the server, before any method is accessed, check whether the user id in request and token are the same.
FYI I am using Firebase authentication and tokens, then use AWS API Gateway to authenticate the access to the API. The user Id I was referring to is in database.
How do you think I can overcome this issue and secure the API?
As long as you make sure to pass the tokens only over secured connections, interception of that token is not very likely. If you then use short-lived tokens (such as Firebase's ID tokens), even when a token does get intercepted it can only be used for a short amount of time.
If a token does get intercepted, you can revoke the token, as shown in the Firebase documentation on managing user sessions.
And finally, you can consider implementing App Check for an additional layer of protection, and check that token too in your own backend.

Any possible way of single sign on service with django rest framework?

I am trying to develop mobile native apps with ionic2 and django rest framework. And I found django-rest-framework-jwt library that support great jwt authentication. However it doesn't refresh token automatically so that users of mobile apps should type their username and password whenver the token expires..
I already checked another stackoverflow question below.
JWT (JSON Web Token) automatic prolongation of expiration
Is there any way that users don't have to type their username and password again? Or Is it ok let token not to be expired and save it local storage of mobile apps so that users don't have to login again?
Thanks in advance!
I've run into the same scenario with our Django and DRF-based projects, and we wanted to implement Single sign-on using JWT. Since the djangorestframework-jwt library had very little focus on providing SSO capabilities between different projects, I have created a new library for this that properly sets up trust definitions and public/private key pairs.
This library provides two types of JWT tokens:
non-expiring session tokens for your primary login application (aka. "refresh tokens")
short-lived authorization tokens for accessing your other apps (these contain permissions given by the primary app)
The client is expected to first login to your primary login application by POSTing an username and password. The client will receive a permanent session token that will allow subsequent requests to the same server be authenticated. These tokens do not contain any permissions/authorization information and cannot be used for SSO into other apps.
Afterwards, the client is expected to obtain and keep updating authorization tokens using the session token. These secondary tokens are short-lived (15mins..1 hour) and contain the permissions that the user has at the time of issuance. These tokens are used to access other services, which then trust the permissions in the JWT payload for the lifetime of the token.
The current version is v0.0.3 (alpha), but we are moving very fast towards a beta and finally production quality release. The API is already relatively stable and should be final by June 30th 2016. The framework will also have full test coverage in the coming weeks, when we reach the beta stage.
Please check the project page and github for the README.
https://pypi.python.org/pypi/djangorestframework-sso
https://github.com/namespace-ee/django-rest-framework-sso
Please let me know if this would fit your use case, and if it has all the features required. I'll be happy to help with the setup.

How to get facebook graphi api acess tokens programatically

I am trying to get data from public pages of facebook using graph api.
This requires acess tokens.But I want to automate the process such that I get the data after ever day but the tokens expire after some time. Is there any method to get the acess tokens programatically to automate this thing ?
Also why it acess tokens are required for public pages ?
The only Token you get without user interaction is an App Access Token. It´s basically "App-ID|App-Secret" (with a pipe sign). This works as long as the Page is not restricted by age or location. In that case, you would need to use a User or Page Token, because Facebook can´t identify a User (and his age or location) with an App Token.
You can also use an Extended Page Token, which is valid forever. But you have to be Admin of the Page for that one.
More information about Tokens:
https://developers.facebook.com/docs/facebook-login/access-tokens
http://www.devils-heaven.com/facebook-access-tokens/
If you want to know why Tokens are needed, you need to ask Facebook.

Facebook Graph API - complete server side auth and API calls

I have an application, that runs on server. On that server is background task, that will post status update on few social networks (Facebook, Twitter, G+). It must be completely server-side.
In Twitter API I'm able to use OAuth header to authorize API request. OAuth HTTP header uses consumer key, consumer secret, access token and access token secret to create the header. With this I'm able to post/update/delete tweets with no user interaction.
How can I do this for Facebook? I found a solution to obtain a long-lived access_token (2 months), but we don't want to regenerate access_token every 60 days. We want to use it for manage our Facebook page - post status updates, but completely server-side.
Am I able to do this for Facebook? Thanks for answers.
PS: I searched stackoverflow hundred-times but with no solution for my problem.
Thanks.
It is not possible for User Access Tokens (they can only be extended to 60 days and need to be refreshed by the user after that), but for posting to a Page you should use a Page Token anyway. An Extended Page Token is valid forever.
Here are some Links to help you get that Extended Page Token:
https://developers.facebook.com/docs/facebook-login/access-tokens/
http://www.devils-heaven.com/facebook-access-tokens/
http://www.devils-heaven.com/extended-page-access-tokens-curl/
A Page Token will post "as Page" btw, but that´s probably what you want. And auto-posting on user profiles is not really allowed anyway, every message has to be 100% user generated and every posting should get authorized by the user.
Pay attention to Access Tokens Expiration & Extentions.
The Page Access Token could be a good solution to only server side calls for testing and data analysis purposes.
Take your User Access Token from Graph API Tool
Extend your User Access Token
Call https://graph.facebook.com/v2.11/me/accounts with your user access token extended
*all calls are GET and this procedure does not use APP Access Token.

When adding Facebook integration to a web app, how do you handle OAuth token expiration and what user data should be saved?

I'm planning out adding Facebook integration to a web app I'm working on. For the most part, it's proceeding smoothly, but I am confused on the proper way to handle the OAuth token.
The sequence of events presented by Facebook here is:
Ask the user to authorize your application, which sends them to a Facebook window.
This will return an Authorization Code generated by Facebook
You then hit https://graph.facebook.com/oauth/access_token with your Authorization Code, which will give you a time-limited OAuth token.
Using the OAuth token, you can make requests to access the user's Facebook profile.
Facebook's documentation has the following to say about token expiration:
In addition to the access token (the access_token parameter), the response contains the number of seconds until the token expires (the expires parameter). Once the token expires, you will need to re-run the steps above to generate a new code and access_token, although if the user has already authorized your app, they will not be prompted to do so again. If your app needs an access token with an infinite expiry time (perhaps to take actions on the user's behalf after they are not using your app), you can request the offline_access permission.
When they say to re-run the steps above, what steps need to be re-run to get a new OAuth token? What data (Facebook UID, Authorization Code, OAuth token) does it make sense to save to my local database?
I would like to be able to have the user continue to interact with my site, and in response to certain user actions, I would like to be able to prompt to user if they want to post something to their Facebook wall.
The access token is time and session based and is unnecessary data to store and have no use after the user have closed the session.
The facebook uid is the only thing you need to identify the user.
Since the Facebook API sometimes is horrible slow you could store the username aswell.
But for identification, all you need is the uid.
The documentation that facebook provides has been updated since you asked this question. https://developers.facebook.com/docs/authentication/.