If I go to the Graph API Explorer, get a User Access Token, and then go to /<page-id>/live_videos I can return a list of live videos from that page, including the status (VOD aka past, or LIVE) and the embed_html.
This is great but the problem is this User Access Token will expire. I want to be able to get this data as part of my website to show visitors whether we are live or not, and if so give them an option to open the video right there on the site. It shouldn't be something a user has to login in to allow my app to access FB on their behalf.
So I tried using an App Access Token which I got by using the App ID and App Secret of my page's 'Facebook App' as described in the Facebook docs here... but the Token that I get from this does not work; it tells me A user access token is required to request this resource.
Why must I get a User Access Token when it's my App (aka my website) that wants the data?
Honestly I didn't think it would be hard to get this information since it is a completely public page; I would have guessed you don't even need to authenticate, but probably just some need sort of identifying token for your app for rate limiting, etc. Is there any method like that?
I have a simple web service and I want to add social login with Facebook and Google using Loopbackjs.
I've already done parts of this editing the example found at this link: https://github.com/strongloop/loopback-example-passport and following the instructions at this one: https://docs.strongloop.com/display/public/LB/Third-party+login+using+Passport.
My problem now is that I need to retrieve user information after login, so that every following editing request on the User model can be direct to the owning User entity.
e.g. The User X want to access to my application:
X request for "example_site_address/auth/facebook";
X will redirect to "www.facebook.com/dialog/oauth?response_type=code&redirect_uri=example_site_address/auth/facebook/callback&scope=email&client_id=XXXXXXX";
After his acceptation, he will redirect to "example_site_address/auth/facebook/callback&scope=email&client_id=XXXXXXX";
Then he will again redirect to "example_site_address/success_fb", this link should give to the client the User entity with which he is logged in.
Using Google this problem is solved because I could retrieve AccessToken information from the cookies, find the User who's owning that, and then send back it to the client, so he can store the UserId and every a following request could be like on this User.
Using Facebook I'm not able to do this, because cookies concern login are encrypted.
I'm a really beginner on this kind of application, so it is possible that my strategy is wrong. Could you help me to do this?
LoopBack Example is using a cookie-parser package (see server/server.js). Cookies are signed but you have an access to them via req.signedCookies property.
I'm sure this is a 101 question but I haven't found a definitive answer yet.
I'm working on an Instagram widget for Adobe Muse based on an open source Javascript client. This requires an Instagram clientID for accessing the API. I've registered one for myself and all works fine. Is the ClientID unique for each person using an instance of the widget on their own site or does it just require it to reference mine?
You'll need only one Instagram client for your widget. It seems that you've registered one already.
Your widget should be able to authenticate each user using your client ID.
Since your widget is using Javascript, you'll have to use implicit authentication.
https://instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
If a user grants access to your client, a unique access token for that user will be returned.
http://your-redirect-uri#access_token=ACCESS-TOKEN
Your widget should use the access token for accessing Instagram API.
You'll find more information on Instagram Developer Portal - Authentication
I would like to let users login to my site using Facebook and I want to obtain a token from FB when the following properties:
For a given user, the token is always the same when they log in with facebok
The token is unique to my app. That is if that user logs into some other app with facebook they aren't given the same token.
Does FB provide anything like this? As far as I can tell the user id that the facebook api returns is the same for all applications.
I know that I could achieve #2 by sending the FB userID up to a server and hashing it with some secret key but I'm trying to make a purely client side application.
Facebook provides a field third_party_id (see: https://developers.facebook.com/docs/reference/api/user/), that is unique to your app.
It’s main purpose is to be used to identify a user without violating their privacy, f.e. when you would have to pass a user id around as a parameter in a public URL or something.
If you ever need to “translate it back”, you can use it to look the user up via the FQL user table (with an access token for your app only, of course).
So I'm developing my own API for my website - I'm mimicking the Facebook JS SDK in regards to how my system works. API client displays a button, popup comes up and the user can log in. Login popup issues an event to the opener window and the parent window now knows the user is logged in. That all works.
What I'm having trouble understanding is how they can verify that the refresh requests are valid. If the API client needs to send a request to the server to ask if the user is logged in and it's all in JS, then everything is transparent. The API client says, "Hi, I'm application 4jhkk2l3bnm389, is the user that's logged in on Facebook also authenticated with me? If so, can you send me a new token so I can make API calls?" and Facebook says, "Oh, you're application 4jhkk2l3bnm389? Yeah, the user is logged in and has allowed you to access their information, here's an access token."
But how does Facebook prevent an outside application that isn't the authentic application from saying, "Hey, I'M actually application 4jhkk2l3bnm389, I promise I'm not lying. Can I have an access token?"
I have no idea how they determine the difference. Obviously if it was all done through AJAX calls in modern browsers then you could just provide an Access-Control-Allow-Origin header. But if a malicious client were to use cURL then I don't think I could ever tell the difference. How does Facebook do it? A good explanation is much appreciated! Thanks!
All access tokens belongs to an app/user pair, and in order for Facebook to return such an access token to the app, these has to be verified.
The app, or client_id, is verified against the domain specified in the redirect_uri - if the page tries to use a client_id/redirect_uri pair it does not own, then it will not receive the access token as this will be passed to the valid redirect_uri (the mechanism the JS SDK uses follows the same rule).
The user, or uid, is verified using the cookie Facebook sets when you sign in.
While you can easily spoof the client_id/redirect_uri pair using curl, the same does not apply to the uid, as you would have to be in the possession of the users cookie. And if this is the case, well, then you could simply grant your own application access.
Facebook uses OAuth 2.0 for authentication. You can find details of how Facebook deals with OAuth right here: https://developers.facebook.com/docs/authentication/. There are many different ways OAuth can be used, depending on whether you're on a mobile device, a page on facebook.com itself, or, in your case, just a web page outside of facebook.com. The details of that final flow can be found here: https://developers.facebook.com/docs/authentication/client-side/.
Basically, Facebook knows what applications you have given permission to view your information. When you run one of those applications, they first make sure you are logged in to Facebook, then they request a user access token from Facebook, essentially saying, "Hey Facebook, I don't know this person, nor should I. Can I get access to their information?". And then Facebook looks internally and if it decides this particular application should have access to this user's information, it sends a user token.
That's the simple way of describing it. There are many different ways the authentication flow can happen, depending as I said earlier on what kind of device the request is happening from, whether this is a page on facebook.com, etc., essentially based on your security constraints. Best to read the Facebook authentication docs referred to earlier for the details since it can get quite tricky.