We use Google Cloud Endpoints with a GWT application. For authentication on OAuth2, we use gwt-oauth2 (http://code.google.com/p/gwt-oauth2/) but it keeps prompting user with a popup window on the first access and every time the token expires. It is not a good user experience as it was before using just Cookie Authentication with Google Accounts.
Does anyone knows any other way to authenticate to Endpoints with gwt without prompt the user with authorization screen, or, at least, without prompt every time the token expires?
I'm unsure if gwt-oauth2 supports immediate mode, but if it does, that's the solution for repeated access prompting with a popup. (If it doesn't, it's a bug/feature request for the library.)
The Google API JS client uses immediate mode to get a fresh token, without a popup window, whenever the user has previous authorized the application (as seen in the documentation). You need to replicate this behavior inside of your library.
You will always get a popup window the first time a user accesses your application, by design.
Related
I want to make an application that runs in the background on a server, and syncs ad information from Facebook to a database on my server periodically (say once per hour).
The application will have no user interaction at all, meaning there is no user to click "I'm okay with Facebook using my info" every time you need to authenticate.
I found this in their docs: https://developers.facebook.com/docs/facebook-login/access-tokens#apptokens
The problem is, it doesn't seem to work. I can generate an access_token just fine. Example here:
$ curl 'https://graph.facebook.com/oauth/access_token?client_id=123456789012345&client_secret=s3cr3tt0k3n12a4zz1345a6fgx5aa3f6&grant_type=client_credentials'
access_token=123456789012345|SomeRandomLettersAndNumbers
However, when I go to use it I just get permission denied errors:
$ curl 'https://graph.facebook.com/v2.6/me/adaccounts?access_token=123456789012345|SomeRandomLettersAndNumbers'
{"error":{"message":"An active access token must be used to query information about the current user.","type":"OAuthException","code":2500,"fbtrace_id":"DQ8ysX2mHCu"}}
Same thing happens when I make the request via their explorer tool found here: https://developers.facebook.com/tools/explorer/
Notes:
I have an app set up.
I am the admin.
I claimed the app on my business account.
I created one ad account.
It is not a Native / Desktop app.
Important one: I can get the info if I use a user token instead of an app token, but this requires me to be on a website, and click through a popup window, which obviously I can't do every hour for my server-side app.
I'm not sure if I have to set the permissions somewhere to allow me to use the access token, or maybe I need to set up a "platform" for my app (none of the available ones seem to fit).
UPDATE:
The answer to this question is to use a system user as documented here: https://developers.facebook.com/ads/blog/post/2016/04/05/system-user-rollout/
I'm trying to build a Facebook-authenticated native mobile app (Windows Phone) that connects to a web service I am creating in Node.
I'd like for a user to:
Log in to Facebook on the mobile app via a native UI or web window
If logged in successfully, create or access server-side user account data tied to that identity
Use the authenticated session to make subsequent authenticated requestsvto that user's data via the native mobile app
My question is: What's the best approach here?
Should I...
Log in the client to facebook locally in the mobile app and pass the Access Token to the node service, and then somehow map the user to my service data based on their facebook account id? That seems grossly insecure if I just pass that token in the URL.
Log the user in via a mobile browser window inside my app, and then redirect back to my Node service in the same window? How do I then make subsequent authenticated requests natively in my app?
Do something else entirely?
Sorry this is so open ended but this is the first time I have tied these things together and although there's a lot of info on each part I've yet to find something that describes the overall pattern / best practice for this design.
Your question is quite opinion based...but still I will try to help.
First of all, you can pass access token in url, its not insecure if you use https. Even if logged into facebook from your mobile app, than also its going to pass a access token in url only. If you mean having the token in http://something.com/access_token, than its not how its should be done.
If you look into the Oauth 2.0 draft you will understand that its done through setting a header Authorization with the value being the token and token_type. Take a good look at the draft.
As your solution I think its fine if you just use the first method mentioned in the question by sending the access token in header as I mentioned in your app and in turn authenticating that token from facebook on each request.
If you think this is just too long a flow for authenticating every request from facebook, than you can get access token by sending request from your mobile app to server and let the server handle the access token and store it in database which you can authenticate each request.
In any case take a look at Passport module, it has facebook and other auth built-in and should be sufficient for your needs.
We are integrating an application as a facebook app at work. I want to be able to detect whether the user has logged in to facebook, and if not, to prompt for authentication.
So far we have successfully used the facebook SDK and the login functionality it provided. However, this causes an authentication popup window to be created by our application, and it is being blocked by most of the browsers, so our priority task is to re-implement the authentication logic not to use popups.
According to the this tutorial from the facebook documentation it could be done either by using event subscription for user status change requests (which did not work when the user is logged out) or by obtaining access token. The problem is that the token is returned as request parameter to the top window (the url I specify as a return url after the user authenticates). Since some cross-domain and browser restrictions exist, I am unable to use client scripting to obtain the value, and I am stuck.
Related questions here have been asked and the common issue is that most apps are being ran on localhost. However, the case with our app is that we have deployed our app to local webserver, that is exposed by a public domain, but still has the cross-domain restriction issues. It is being referenced by its public domain name within the facebook app configuration. I am completely confident in that the domains are fully accessible from outside.
In general, our case is that we would like to host the app while it is being used by facebook users. Perhaps this approach might be incompatible with our requirement? Is it possible to configure cross-domain communication to avoid the issue? Are any other ways to do avoid facebook login popups?
First of all, default settings for popup blockers in modern browsers are so that they only block popups that are called without user interaction. If you call FB.login automatically on page load, it is likely to get blocked. But if you offer a link/button to the user saying “log in here” and only call FB.login on click on that link/button, then the popup is rather likely to be shown and not blocked.
If you are not willing to do it that way – then your other option is to use the server-side auth flow. You can just redirect the user to the auth dialog, which will happen in the same window, and he will be directed back to your app afterwards.
I am working on a product which has both a desktop web site and a native iOS application. We are providing Facebook connect as a login option for our users in both contexts.
My intention was to share the same Facebook tokens via a secure JSON API for use in both contexts: when a user signs in on the web, the token is stored to our backend so that when the mobile client next runs, it can download the token and use it as well, and vice-versa. (* The detailed reasoning for this approach I explain at the end of the question, and is not essential to the question.)
The problem: when the iOS client uses a token to preset a feed dialog, if that token is generated by the web using the server-side flow, the dialog webview renders an error:
"An error occured with {my app name}. Please try again later."
This is reliably reproducible:
Generate a new access token using the server-side flow. Make sure you request publish_actions permission since you'll be using the feed dialog.
Using an incognito browser window (to get an empty cookie jar), view the m.facebook.com page that the iOS feed dialog would render in its webview: https://m.facebook.com/dialog/feed?access_token=SERVER_SIDE_FLOW_ACCESS_TOKEN&app_id=YOUR_APP_ID&redirect_uri=fbconnect%3A%2F%2Fsuccess&sdk=2&display=touch
Alternatively to #2 you could do all the work (which I have done already) of creating a dummy iOS app with the Facebook SDK, instantiating it correctly and presenting the dialog. It's just easier to go straight to the m.facebook.com feed URL for the purposes of reproducing the error.
If the token was generated by the auth flow initiated by the native Facebook iOS SDK instead of the server-side auth flow, the above feed url works perfectly fine, as expected.
Additionally, either token (mobile or server generated) works perfectly fine for posting feed items directly via the graph api. The problem is really just with the mobile feed dialog.
Is Facebook intentionally disallowing server-side generated tokens from operating in mobile feed dialog contexts?
Is this a bug with the feed dialog endpoint on m.facebook.com?
Or, hopefully, am I doing something wrong?
Why do I want to share tokens?
Since the offline_access permission is being removed, each client (web vs mobile) can benefit from having the other client refresh the same token when the user is active. This will lead to fewer instances of token expiry, and therefore fewer cases in which users must re-authenticate from scratch.
Likewise, users are not asked so frequently to approve additional permissions, since each client can benefit from the other's permission augmentations.
The tokens you get from the server side auth are different from the ones on the client side (I look at iOS/Android as client).
The server tokens are long lived one (60 days) while the client ones are short lived (a few hours).
The server side flow adds another layer of security where your servers authenticate against the facebook servers, which is probably why you get a long lived token automatically when using this flow.
If you try the debugger with an access token you will receive information about the token, such as the "origin" of the token.
For example a token generated from a client side auth (using js) has "Origin: Web".
That means that facebook indeed differentiate between tokens.
I'm not 100% sure about this, but from what you're saying it does sound like facebook is limiting the UI to the usage of client tokens and not server side ones, probably because the dialogs let the user do things without the need of the app to get permissions, and so if you have a 60 days token your app can then use it instead of the user and do things on his behalf with out having his permission.
I'm just guessing here.
What I would recommend you is to use the server token only on the server side, and let the iOS client handle his own token.
According to the Handling Invalid and Expired Access Tokens guide, it states:
iOS native applications
API errors are handled by the FBRequestDelegate interface. When you
detect an access token is invalid or has expired, your application
will need to multi-task over to the Facebook iOS app. Assuming the
user has not deauthorized your app, they will be immediately
multi-tasked back to your iOS application with a fresh, valid access
token.
Which means that you don't have to worry about the token getting expired on the client side.
Per the SDK, I am using the logout.php with redirect:
https://www.facebook.com/logout.php?confirm=1&next={SOME URL}&access_token={ACCESSTOKEN}
It is logging me out fine, but it's also logging the user out of facebook. Isn't there a way of logging out of my OAuth session without logging out of facebook?
Yes, I ran into this same issue myself. Dont do logout.php or JS SDK's FB.logout(). Rather call the Graph API with an HTTP Delete command to me/permissions. That will kill the access token, remove the app from the user's app listing and maintain their browser's cookie for facebook. You can call it either server side or client side. Here's the client side Javascript SDK way:
FB.api("me/permissions","delete", function(response){/*do something if you want*/})
This is one of the many annoying things about developing on the Facebook platform. The only way to log out via a browser session is to use their javascript logout function or the redirect like you tried but either will also log the user out of Facebook which is very annoying from a users perspective. The problem is you can't access the cookie they set for your app to delete it due to cross-domain restrictions so you are stuck with the limited options Facebook provides. If you are not prompting for offline_access, you could just forget the users access token and it will expire after an hour. Although the problem still exists that the cookie is still set for within that hour.