Is it possible to accept paypal payment directly inside an iOS App (i don't mean via the Paypal iOS app, but my own app) without having our own server to validate the return token? I think it is possible with a javascript button inside a webview, but can it be a native iOS function?
You could do it... but it would involve enormous risk. The reason is that you would have to store your credentials inside the app and then make the call directly. Anyone could then extract the credentials and start using them for their benefit (i.e. MassPay themselves from your account).
The only way to ensure they don't get your credentials is to keep them server-side, where the client has no access to them.
Related
TLDR: All I want to do is secure my cloud function in Parse so that it only accepts requests from my iOS app. How can I do that?
Longer version:
I recently got started with using Parse for a client side app I'm building using a Google API.
Before using Parse, my issue was that the Google API calls from my app were not secure. I tried a Man in the middle attack on my app, and I was able to successfully get the bundle id and app id (Google claims some form of security is achieved by ensuring that the call is from the correct bundle id that you can specify on their console). So despite using SSL, seems like it was easy to get this information. Now this Google API is paid, so someone could easily abuse my key when I release my app and raise my bills.
I was anyways also thinking of doing some lightweight work in the backend, so I figured to use Parse. Now the call to the Google API is done in Cloud Code. But a new problem I'm facing is how to secure calls to the Cloud function I've defined in Parse? The Parse App ID and Client Key aren't secure at all.
All of Parse's blogs keep talking about creating users and defining ACLs etc. But in my case, there is no data in my Parse app and there is no user per se. It simply calls the Google API and returns the result. All I want to do is secure my cloud function so that it only accepts requests from my iOS app. How can I do that?
The inherent security risk here is that any key you store in your app is vulnerable, for that reason encryption is also vulnerable. My recommendation is to use the automatic user in Parse on your iOS app, you could even throttle excessive requests/abuse by a single user. By creating and using a user you are able to gain the benefits of ACL which appears the best security option available in Parse currently. At that point you send the automatic user in your cloud code request and verify it's a valid iOS user.
I would like to play videos inside an IOS web view with Cordova.
Videos must be available only inside this app.
I don't have any domain to restrict access, because it's a web view inside a native app.
Is there a way to use HTTPS with Javascript to authenticate with an API token, then play each video with this token?
Can anyone provide a specific script example to do the job?
It is not possible to do this in such a way that someone could not break it because an attacker could install a man-in-the-middle server with a certificate created using their own certificate authority and then sniff the data and use it outside the application.
However you could make it more difficult, by creating "single use" keys that you send to the device using the notification service every time a key is used, you invalidate it and create a new key for the next use. This would mean that someone trying to get around the system would find it very difficult to have more than one client using the content at any given time.
Given that that is the best you can do, why not simply have users authenticate themselves and not allow multiple sessions to be active for the same user?
I have to call payment gateway API from iOS code. Problem is it needs merchant credentials and I feel insecure embedding the merchant credentials in code. If someone somehow reverse engineer the code and get the credentials then the client is dead. Any advice?
I found this post Does Apple modify iOS application executables on apps submitted to the App Store? which says that app binaries are encrypted by Apple be default. Does it mean I can safely embed the credentials in code?
NO! Instead of adding the credentials to iOS app you should think about setting up a server which handles the interaction with the API, you are talking about, and let the app only interact with your server. So you can store the API key on your server and can limit whats possible by the user on server side (which will be much harder to abuse).
we are developing an iOS App using Adobe Flex/Air. The app uses a web service that needs user authentication via facebook login. At the moment, we use server side authentication: There's a login URL displayed in a WebView where the facebook login is done. This way, we get an access_token that can be used on the server side.
This works perfectly but it would really be much better if we could use Single Sign-on with the facebook ios app. As far as I have read, this should work on the client side but I haven't found a way to authenticate the user on the server side.
facebook's access_tokens are valid either for use on the server-side or for the client side so an access_token from the client-side login won't work for the server side.
Thanks in advance for your ideas,
Henk
As far as I can see, you're making this far more complicated than it's really intended to be. Leverage the Facebook iOS SDK, and all of the heavy lifting involved with authenticating the user within your app is handled by the Facebook SDK. There's no need to independently provide sign-in sheets and manage access token exchange between the app's local storage and Facebook's servers without the convenience of the entire Facebook SDK.
This link shows you how to implement SSO natively within your iOS app. It's real simple.
http://developers.facebook.com/docs/mobile/ios/build/#implementsso
Then, I understand that you're keeping authentication information or central user database information on an external server. The best way to synchronize the information between the FB client and your own servers is to simply check the login information returned by the FB SDK with your server after you receive it.
Here's a simple breakdown:
Log the user in using Facebook's standard SDK (see the link above).
In the -didLogin method (or whatever the equivalent is in your Adobe AIR environment), check the access token returned by FB with your server. Not sure what server architecture you're using, but it's safe to say that this will go on outside of the FB SDK. Also, save the access token in your app's user defaults so that the user won't have to login again next time. This whole process should (and inherently will) feel much quicker than it sounds.
If the check with the server returns successfully, notify the user of a successful login. If not, display an error view explaining the reason the user was rejected/not logged in.
Why do it this way? The reason is fairly simple. It's safe to assume that the reason you're having a user login to your app via Facebook is so that you can make requests for the user's Facebook information (i.e. feeds, photos, likes, comments, etc.). The easiest (and best) way to do this is through the FB SDK its self. The SDK takes care of a lot of stuff behind the scenes like access token validation over time, extension of token life, validity of token, and so on. This way, you won't have to worry nearly as much about syncronizing the server information and real-time client information when changes take place. Just authenticate via the FB iOS SDK, and do the rest of your own processing afterward.
Comment below if there's anything I should clarify or even if I missed the point of your question entirely--I tend to get on a roll and may stray from the point. :)
Cheers!
The Kraken
I have a website that requires any user to be logged in using the Facebook auth system.
On the other hand I am making an iOS App that needs to consume functionalities of the website. I implemented the SSO system on the iOS system but I don't get how I'm supposed to call my webservices in a way that tells the backend that "it's ok, I'm authenticated on the iOS app".
Is there anything to do with the signed_request parameters on the iOS side? If yes, I didn't find anyway yet to get that parameter.
Do you have any clue to help me deal with my issue?
Thanks
https://developers.facebook.com/docs/authentication/signed_request/
The signed_request parameter is utilized to share information between Facebook and app in a number of different scenarios:
A signed_request is passed to Apps on Facebook.com when they are loaded into the Facebook environment
A signed_request is passed to any app that has registered an Deauthorized Callback in the Developer App whenever a given user removes the app using the App Dashboard
A signed_request is passed to apps that use the Registration Plugin whenever a user successfully registers with their app
Does iOS use any of these?
** EDIT **
Ok thanks, can you edit your answer and add the fact that I can't
access the signed_request parameter? – MartinMoizard
From Martin: iOS cannot access the signed request parameter probably because iOS is not a webserver that is able to accept HTTP Post paramteres.
I am struggling with this same problem, and it seems that OAuth is actually an authorization protocol, not an authentication protocol. See:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
Seems like the signed request would solve this problem nicely. Not sure why we cannot get them on iOS. Best I can figure out is I need to pass my access_token from the iOS client to my server, and then it can ask graph.facebook.com what user it represents.