My question is related to, but not exactly, this question.
I am currently working on a business directory Web site (similar to Yelp), in which businesses have their own pages. Let's call this app DIRECTORY_APP.
Businesses might want to have their latest Facebook status update shown on their pages hosted on our directory. Let's pretend we have a business named BIZ_1. The assumption is that those pages are public pages.
Apparently the Facebook Graph API can be used for this purpose. So I can send a request to Facebook to retrieve the latest status updates for BIZ_1:
https://graph.facebook.com/BIZ_1_PROFILE_ID/posts?
access_token=DIRECTORY_APP_ACCESS_TOKEN
&callback=callbackName
However, if I use this from the client side, our Web site's access token will be exposed to the public, so this is not a reasonable solution.
Now in the aforementioned question, Anatoly mentions that we can retrieve the access token by sending this request first:
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET
&grant_type=client_credentials
However if someone inspects the Network log, this will also expose our Web site's access token (is this correct or is this a different type of access token?). This solution also exposes our web site's app secret (is this safe?).
So to summarize, what's a safe way in which I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook?
I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook
You cant do that without login.
And I guess access token is not exposed.
Maybe the smart trick here is to use a social plugin. The Like Box will do what you want, without any issues. But, it's not greatly customizable. Even so, it's possible to get it looking nice on a page!
It also skips any login issues you mentioned.
I found the answer after some Googling. In short, the answer is no.
And here's an excerpt from Facebook:
Security Best Practices
App Secret and App Access Token
The App Secret is used in some of the Login flows to generate access tokens and the Secret itself is intended to secure usage of your App to only those that are trusted. The secret can be used to easily create an App Access Token which can make API requests on behalf of any user of the app, which makes it extremely important that an App Secret is not compromised.
Therefore the App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app. This applies to all methods of code that are not secured like client-side code (such as HTML or Javascript) or native apps (such as iOS, Android or Windows desktop apps) that could be decompiled.
We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token. For this reason, if your 'App Type' under Advanced Settings in the App Dashboard is set to Native/Desktop we assume that your native app contains the App Secret or an App Access Token in the binary, and we do not allow calls signed with an App Access Token to proceed. The API will behave as though no access token was provided.
If your App Secret is compromised, you should reset it immediately in the Basic Settings of your App Dashboard.
Related
Following up on the design outlined in Design for Facebook authentication in an iOS app that also accesses a secured web service, and specifically the concern listed in https://stackoverflow.com/a/12912616/5154090: what would be the mitigation?
Specifically, I have a web server that exposes a REST API which is consumed by a mobile app. I'd like users to authenticate to the server (via the app) using Facebook.
Now, an apparently common flow is for the app to redirect the user to Facebook, where they will login with their credentials. The app will then get a token which it will send to the server, and the server will validate the token using the graph API.
But how can the server make sure that the token really came from the app? Specifically, what's to prevent a malicious app vendor from re-using my app ID? After all, the app ID is hardcoded into the app and can therefore be extracted and used by a malicious app. If users log into that malicious app with Facebook, then the malicious vendor can get tokens with my app ID and can impersonate users of my service.
How can one protect against this?
To summarize for anyone else who happens to contemplate this - there is indeed no way to prevent the client ID from being spoofed. This is one reason that developers are discouraged from using the OAuth implicit flow in native apps as pointed out by Andre D in https://stackoverflow.com/a/17439317/5154090:
the use of the Implicit Flow with native apps is NOT
RECOMMENDED.
(see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-09#section-8.5).
In practice, if anyone mounts this attack, then the user will download App A (a malicious app) and will then be asked to authorize App B to make actions on their behalf. As far as I can tell, this is generally the only indication that an attack is taking place.
I build API for post on my community of VK. But I check my permission for my app, and I have all permissions, but not load WALL permissions.
In the scope for OAuth, I put all scopes and not work the WALL. I check the "Api.console" and they have "Access to Wall - The application has access to your wall", but in my app not appear.
This is the response:
{"error":{"error_code":15,"error_msg":"Access denied: no access to call this method","request_params":[{"key":"oauth","value":"1"},{"key":"method","value":"wall.post"},{"key":"owner_id","value":"-*********"},{"key":"from_group","value":"1"},{"key":"message","value":"New post on group wall via API."}]}}
I check other services and if work.
You can't call wall.post (and a lot of other methods) with a non-standalone applications. It seems like your VK application is of type Website or iFrame - they have limited access to the API methods.
However, while you can't call this method from non-standalone applications, can via the Open API (it's a JavaScript SDK for Website applications) or the JavaScript SDK for iFrame applications.
When you call wall.post via these SDKs, a confirmation window will appear where the user needs to confirm the wall post before sending it:
Standalone applications are designed to be used in apps like mobile or desktop clients or browser extensions (because they don't have CORS limitations and may read any tab). There is absolutely no ways to get a user's standalone access token without limitations if you are trying to authorize them via website.
If you are building website or something and need wall.post for service purposes (e.g. news cross-posting), then you may get your token and save it anywhere in site configuration. Open this address:
https://oauth.vk.com/authorize?client_id={APP_ID}&scope={PERMISSIONS}&v={ACTUAL_API_VERSION}&response_type=token&redirect_uri=https://oauth.vk.com/blank.html
{APP_ID} - your standalone application ID (may be found in application Settings).
{PERMISSIONS} - comma-separated list of permissions. Don't forget the offline permission to get token that doesn't expire.
{ACTUAL_API_VERSION} - VK API version.
Example:
https://oauth.vk.com/authorize?client_id=123456&scope=wall,offline&v=5.60&response_type=token&redirect_uri=https://oauth.vk.com/blank.html
Note that redirect_uri=https://oauth.vk.com/blank.html is required to get token without the above mentioned limitations.
After you grand your application access to your account, access token without limitations will appear in your browser address bar. Just copy it, save in your configs and feel free to call any methods you want.
Late but...for this you need to first create a sort of "demo" app for VK using the standalone app type which would issue you an access token inside the address bar when you set the redirect link to https://oauth.vk.com/blank.html
This access token would allow you to share to your personal profile wall.
Then you need to contact VK support and display your app in action. Once they approve it then you'd be able to use a "Website" app that has OAuth style authentication
Facebook documentation states that
the App Secret or an App Access token should never be included in any
code that could be accessed by anyone other than a developer of the
app. This applies to all methods of code that are not secured like
client-side code (such as HTML or Javascript) or native apps (such as
iOS, Android or Windows desktop apps) that could be decompiled. https://developers.facebook.com/docs/facebook-login/security#appsecret
For this reason, if your 'App Type' under Advanced Settings in the App
Dashboard is set to Native/Desktop we assume that your native app
contains the App Secret or an App Access Token in the binary, and we
do not allow calls signed with an App Access Token to proceed. The API
will behave as though no access token was provided.
Therefore if you embed App Secret in your app and tell Facebook about it, it will simply stop working with OAuth (I have also tested this, when you check that option, Facebook stops validating the secret).
but Xamarin.Auth 1.3 (latest stable) requires clientSecret (in OAuth2Authenticator class clientSecret is the required parameter) and uses it to obtain Facebook access token when user successfully logs in.
So is it a bug, is there a workaround, or Xamarin.Auth is useless with Facebook for now?
OAuth2Authenticator contains multiple constructors and there is one that does not require ClientSecret:
public OAuth2Authenticator (string clientId, string scope, Uri authorizeUrl, Uri redirectUrl, GetUsernameAsyncFunc getUsernameAsync = null)
This one will allow OAuth2 Implicit flow and thus does not need a client secret to be stored within your application's code.
Ref: https://github.com/xamarin/Xamarin.Auth/blob/9c19d90e52994188def9e12e0bbc981a3943a752/src/Xamarin.Auth/OAuth2Authenticator.cs#L110
Let's not confuse things. This has nothing to do with Xamarin.Auth.
There are two major options for OAuth2:
Implicit flow
Authorization code flow
The implicit flow does not require a client secret. The implicit flow is typically used with mobile apps, since they cannot keep a secret (you could disassemble the app binary and find the secret). Same goes with Javascript or desktop apps. The only way to protect the secret is if it is stored on a server which cannot be accessed by third parties (=the users).
The authorization code flow uses the client secret as an additional protection, the secret identifies a specific party, like a server.
So what does Facebook state? They say, if you configure your app to be a native/desktop app in Facebook's dashboard, they assume (!) that you store the secret in the binary, because: where else would it go? As a consequence, the secret is no longer a real secret, hence the Facebook API acts as if the secret was not there.
Two solutions:
Either you configure your app as not native/desktop (I don't know which term Facebook uses, maybe "Server")
or you use the implicit flow which was designed for mobile clients.
And to answer your initial question: yes, Xamarin.Auth supports Facebook's OAuth2, because it is just like any other OAuth2.
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.
I need to post message on a certain FB page as a owner by cron, using php and ZF 1.1.X. For this small issue, I don't want to create a full OAuth stack. Is it possible to communicate with FB API (it's desirable, PHP SDK for FB) without it, such as twitter with his precreated access tokens (Access token, Access token secret)?
As long as you need an active user access_token to retrieve desired data this is not possible to skip OAuth flow.
Without authenticating user you only have application access_token (in old format APP_ID|APP_SECRET, but it's still works) and only limited access to most of Graph API endpoints and Application settings.
Actually there is nothing hard in implementing the user authentication with OAuth flow and it is completely transparent with usage of PHP-SDK.
Just look at the sample code in documentation for server-side authentication
Yes, you need to build an app and then authorize the page via the app while requesting the manage_page permission.
You should make yourself familiar with the Server Side Auth process as well.