I'm having an issue with Janrain Engage (specifically for the iPhone). I'm using the server-side tokenUrl option to complete my authentication process. To configure this way, I initialize my jrEngage object like this:
self.jrEngage = [JREngage jrEngageWithAppId:appId andTokenUrl:tokenUrl delegate:self];
Since I've specified a tokenUrl, the Janrain library automatically posts the one-time auth_info token to the URL I've specified. My server then uses this token to request the auth_info data from Janrain. I'm using the Janrain example code to make this tokenized request from my PHP server.
For some reason, this works fine when the "One time use auth_info tokens" setting is off. When I turn it on, however, I get error code 2 "Data not found"... I want the security of the single-use tokens. Have I already used the token somehow?
Note: I can see that the SDK is indeed passing the token correctly to my tokenUrl, so that doesn't seem to be the problem.
If it matters, I'm using the CodeIgniter framework on the server side.
Thanks,
Steve
Steve,
Token URLs used with the iOS library (or the upcoming Android library) require multiple use tokens -- the NSDictionary parameter of jrAuthenticationDidSucceedForUser is populated with data gathered by using the token.
Edit:
In May we updated Engage to address this issue, auth_info token URLs for the native mobile libraries no longer require multiple use auth_info tokens.
Related
Time ago it was easy to make a distinction between desktop and web applications, but today while reading while the documentation I've noticed that this difference is less pronounced.
I'm using the Facebook::Graph module to create a desktop application, but still can not go beyond the stage of configuration. I'm stuck at authentication phase:
my $ q = Plack::Request->new($env);
$fb->request_access_token($q->query_param('code'));
(http://metacpan.org/pod/Facebook::Graph)
It keeps telling me "$ env is required".
Reading the documentation I've realized that Plack is only concerned with web applications.
(http://metacpan.org/pod/Plack::Request)
Can you confirm this? If not, how do I get past this step?
It would not be a problem getting the access_token using Mechanize and then making a GET request as described in the documentation, but I do not want to complicate my existence, so if there are other ways...
A bit late, but there's a workaround.
To get an access token, take a look here:
https://developers.facebook.com/docs/howtos/login/login-for-desktop/
Just create a client with Mechanize or whatever you want and login with the desidered credentials
Perform the request as described
Move on from the authorization page
Parse the response and get the token
$fb->access_token($token);
http://developers.facebook.com/docs/reference/api/application/ says:
Note: Applications that are configured as Native/Desktop apps will not be able to make API calls that require an application access_token.
So it's not a Plack, it's Facebook who requires your app to be web.
But if you may avoid access_token request, it might work.
I have a Facebook canvas app. I am using the JS SDK to authenticate the user on the browser-side and request various information via FB.api (e.g. name, friends, etc.).
I also want to persist some additional user information (not held on Facebook) to the database on my server by making an ajax call:
{ userFavouriteColour: "Red" }
To save this on the server and associate with the correct user, I need to know the Facebook uid and this presents a problem. How do I pass the uid from the client to the server.
Option 1: Add uid to the ajax request:
{ uid: "1234567890",
userFavouriteColour: "Red" }
This is obviously no good. It would be trivial for anyone to make an ajax request to my web service using someone else's Facebook Id and change their favourite colour.
Option 2: On the server, extract the uid from a cookie:
Is this even possible? I have read that Facebook sets a cookie containing the uid and access token but do I have access to this cookie on my domain? More importantly, can I securely extract the uid form the cookie or is this open to spoofing just like option 1.
Option 3: User server-side authentication on the server:
I could use the server-side authentication to validate the user identity on my server. But will this work if I am already using client-side authentication on the browser? Will I end up with two different access tokens? I would like to make FB.api requests from the browser so I need the access token on the client (not just on the server).
This must be a very common scenario so I think I'm missing something fundamental. I have read a lot of the Facebook documentation (various authentication flows, access tokens, signed_request, etc.) and many posts on SO, but I still don't understand how client-side authentication and server-side authentication play nicely together.
In short, I want to know the user's identity on the server but still make requests to the Facebook api from the client browser?
(I am using ASP.NET and the Facebook C# SDK on the server)
EDIT: Added bounty. I was hoping to get a more deifnitive, official recommendation on how to handle this situation, or even an example. As said, I have already read a lot of the official FB docs on authentication flows but I still can't find anything definitive on how client-side and server-side authentication work together.
Option 1:
The easiest way I can think of is to include the accessToken in JS and pass it with the ajax call.
Option 2:
Using the same as option 1, but instead of sending just the accessToken, send the signedRequest.
On the server side you can decode it using (TryParseSignedRequest method) which will give you the UserID :-)
Note: signedRequest is encrypted with the application Secret. you are the only one who should know it, so you are safe on that end.
Disclaimer:
I have no coding experience in C#, but a little search in google gave me this:
Facebook C# SDK for ASP.NET
Making AJAX Requests with the Facebook C# SDK
It's very simple actually.
When the user loads you app use the server side authentication, get the access token and load the user data by issuing an api request from the server.
On the server side you'll have everything you need and it's sandboxed.
When the page renders for the user, using the js sdk get the user authentication data, you should be able to use FB.getLoginStatus since the user already went through the server side authentication.
Now on the client side you also have an access token which you can use to get the user data from the graph api.
The two tokens will be different, and will also have different expiration, but that should not be a problem, both token should work properly as you'd expect them to.
Since both sides have their own token and a way to make requests to the api, there's no need to send any fb data between them.
So the 3rd option you mentioned, to me, sounds the best, and it's really simple to implement that too.
Edit
All facebook SDKs are just wrappers for http request since the entire fb api is made on http requests.
The SDKs just give you easy and shorter access to the data with out the need to build the url yourself (with all the different possible parameters), make the request and parse the response.
To be completely honest, I think that stop providing a way for the C# SDK to support server side authentication is a very bad decision.
What's the point in providing a SDK which does not implement the entire api?
The best answer to your question, from my experience, is to use both server and client side authentication, and since the C# SDK does not support it, my advice to you is to create your own SDK.
It's not complicated at all, I already implemented it for python and java (twice), and since you'll be developing it for your own needs it can be tailored for your exact needs, unlike a public SDK which should support all possible options.
2nd Edit
There's no need to create a completely new SDK, you can just "extend" the ones you're using and add the missing parts that you need, like sever side authentication support.
I don't know if it's language specific but using both server-side and client-side authentication does no harm.
You can work on option 2 but yes, that will be also vulnerable to spoofing.
Doing option 3, you will be having a single access token for that user session, so that would be the best choice according to me since you always have chance of spoofing when passing user information from client side.
I had exactly the same question recently. It's option 2. Check this post from the Facebook blog.
To be honest I am not enough of a hacker to know if you could spoof the UID in the cookie, but this seems to be the 'official' way to do it.
EDIT: to the other question under option 2, yes, I believe you have to access this cookie on your domain.
I am developing an IM client for iPhone, which will have support for an FB account as well. I am using facebook-ios-sdk for getting auth token.
But whatever token I fetch, it does not contain any "|" character as a delimiter. Isn't it supposed to be like <app-id>|<session-id>|<digest>? Thats what I have read. Now, there is no such delimiter. How do I go about fetching the session key now? Or is there any new method for XMPP communication?
Further, is this one of the changes in OAuth2? I see that it will be deprecated from Nov 5 (as of latest update), so the delimited string will not work after that? So that instead of using older authentication mechanism, I should be working on the new mechanism?
I would be really grateful if you could provide some documented evidence regarding this. Thanks.
from where u get the said format?
the access token that you received is likely to be an encrypted token. In your fb app settings, see if the option "OAuth migration" is enabled or not. If it is enabled, then try to set it to disabled and see if this helps.
I found what I was looking for here:
Any way to pull out session key from access token returned by Facebook iOS SDK?
So the point is that with Single-sign-on, we cant get a token that can be used for xmpp. So if you want to make a chat app, you must use the dialog method, and for that, make the changes as suggested in that answer.
i'm in the early stages of developing an API for my site so that third party developers can build an iPhone application for it. The API would have a limited subset of the functionality of the full site. The trouble i have is around security and authentication for the user who downloads the application. I have come up with the following options:
The user enters the same credentials they use on the site to authenticate themselves. My API would then take the credentials when accessing information specific to the user. This is my least preferred solution as the third party application could log these details and use them maliciously on the full site.
Each user generates a unique key on the site which they can then use on the app to login. My API would take the api key as an argument when accessing information specific to the user. The main problem though is that any application can do what they like to the user once they gain access to their key even if the user has not given the application permission to do so.
To overcome the above problem the third party developer would have to register their application with the site and then the user would need to generate a unique key per application they wish to use. This would then be used to login. This is my preferred solution as each key is unique per application and user i can tell which application called the api and whether the user approved it.
My final option is to implement oAuth. We are currently waiting for the 2.0 version to be finalized and do not have the time to keep updating our code as the spec may change.
This is the first API i have had to build and i was wondering if i have understood this correctly? I'm assuming in option 1 the application could log the user credentials and use them maliciously but how does twitter overcome this issue with their third party applications? Or is it simply up to the user to trust the application they are using? If this is the case then would option 2 and/or 3 be feasible in the meantime until i switch to option 4.
I'd appreciate your feedback. Thanks
OAuth 1 and OAuth 2 are both viable options. But you will come a long way with basic authentication aswell (as long as it is over SSL). Don't be scared :)
I've implemented an API provider over OAuth 1.0. And since there are so many ready made libraries for OAuth1.0 for many platforms I would not be scared of using that either, much of the work has been done already, both for you as a provider and for third party implementors.
Anyway: you can always couple basic authentication with some very simple signing of the request using an application key and secret, say for example that as a third party developer you have to call.
https://yourapi.com/?user=11111&password=232123&random_string=23123&api_key=THIRD_PARTY_KEY×tamp=1212121212signature=efefefefefef
where the API implementor has to sign perhaps the random_string, timestamp and api_key with the secret. Then you would at least have a way of shutting down malicious apps.
I'm building an iOS app which will communicate with a set of .NET WebServices. I'm trying to find a way to ensure on the WS side that the calls being sent actually came from the iOS app.
There is, of course, a "login" method which requires a username/password combination. I would like to add a "security token" to this method, which I can use to validate that the request is coming from the iOS app.
Since this is a parameter to the login method, is must be something known by the app and the web service BEFORE a valid login occurs. Additionally, it should be something which is impossible (difficult?) for another application to fake.
Are their any best practices / standard methods for this sort of exchange? Am I even thinking about the problem in the correct way?
Thanks in advance!
Take a look at the oAuth specification (used by Twitter) it requires that a user is verified first, during the process a series of tokens are exchanged, and then the token is used to sign the data during subsequent data exchanges.
It works on the principals of public/private matched keys, so you have one key that is always kept a secret.