Hello me and friends are planning on taking on a big project. My two friends are going to be building iOS and Android apps and I will be making the server back end. I recently started developing with RoR and have fallen in love with Ruby. Now here are my questions:
Little more background:
I only want a private API for the android and iPhone app. I do NOT want a full fledged OAuth authentication process. Doing some research I think I will go with basic HTTP authentication.
1. My App uses cookie based authentication meaning a cookie has to be passed with each subsequent request. So will my friends need to have to store a cookie and on each subsequent request to the server send the cookie along with it?
2. How do I go about making the API private? I know in OAuth there are consumer secret and consumer key. I know if anyone could simply figure out the URL schema they will be able to have access to the API. How do I protect my back end from request from unknown users? (Hard coding strings in the Apps themselves?, Checking headers for device type?)
3. Should I only build the API now and worry about a web app later? Or would it be too horrific of an experience to go back and build a web app (Although I really do actually want the web app to be more significant than the mobile app
Here is a great article explaining exactly what you're looking for : securing an API without setting up a full OAUTH provider :
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
Works great (even if the solution is finally not so far from oauth ;)
Related
I am implementing Stripe Payments in my iOS app and i obviously cant store credit card information over the iOS app so i have to create tokens and send that to the server to be charged etc.
My question is how can i communicate iOS => server and vice versa
My web app is in Rails by the way.
I read in some places that i might need to create a API on my server? then call it from my iOS side?
if anyone has an idea on how to do such a thing please let me know, i would appreciate it a lot.
Yes, you must create (or update) your Rails application to expose an HTTP API, which usually communicates using JSON. Your API will need to respond to POST/GET/whatever requests the iOS app make and behave correctly based on what you expect to do (do something with some tokens from my understanding).
Please notice though that handling payments and not having already the knowledge on how to do such a thing might be dangerous for the end user.
To give you a general overview of the process:
Create Rails routes, controllers, models required to manage the logic of perform a payment from a token, this is entirely your job unless the Rails app you are working with, already support this
Update your iOS app to send, probably with a POST request, the token you talked about, you'll probably need to define some sort of authentication protocol, look into JWT or something similar, you won't have cookies at your disposal in the iOS app
It's a long but interesting task
I'm having some trouble understanding the Instagram API and can't seem to find a clear answer online. What is the difference between Server-side flow and Implicit flow in terms of security? I understand there is an additional step for exchanging a code for a token when using Server-side.
I am in the middle of developing an IOS app that uses the server-side flow. I am storing the client-secret within the IOS app itself and am not using an actual web server for any part of my requests. Does this method pose any security issues as the API states: "You should never ship your client secret onto devices you don’t control". Do all IOS apps using the server-side flow have a matching server side component or am I missing something here?
The method above is working for me and I am able to access the instagram API. However, I am now running into the 30 like per hour limit and want to figure out how to lift this. I understand that I need to send a signed request to the API using X-Insta-Forwarded-For header. Can this be done within Swift/Objective-C? I am having a hard time find a method for sending this information. The closest I have come to an answer is in the following post: Instagram Signed API Call from iOS
Can this be done? Thanks for the help!
I am trying to create an ios App that talks to a backend API written in nodejs. The backend also has an accompanying webapp also written in nodejs. The idea is that you can login (using facebook-js) on either the app or the webapp and post things to to.
My question is this, let's say that the user decided to login using the ios App, then call some backend API method to post an article, how do I make this work without essentially forcing the user to login twice?
Not sure if I'm making sense, any help would be greatly appreciated!
As Facebook uses OAuth for the client authentication, it's relatively easy to store the Access Token resulting from the login process somewhere on your server, and use them later.
Have a look at Design for Facebook authentication in an iOS app that also accesses a secured web service
Also, see https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.1 which outlines the login process and the storage of Access Tokens.
We have a web application that supports Facebook and Twitter login/signup via oAuth (and can also post to FB/TW). Now we are building a mobile client and naturally we want people to be able to login-signup via FB-Twitter on mobile as well, on iOS even using system-integrated accounts.
Now mobile app and our server app are two different apps, however, and if I get oAuth correctly, we'll need to have two authentications: one for a mobile client (system account can be used), another one for a server (we'll have to show WebView for it).
Yet some existing apps seem to be fine with single authentication only (e.g. Flickr and Foursquare! At least 4sq seems to be fine with iOS system FB account only. How is it possible?
Do they share consumer key/secret between mobile and web app making it essentially the same app?
Do they use some FB-specific extension to oAuth
Do they only use auth token wherever it comes from making it a user ID?
Something completely different?
Old question, but this may help someone who finds their way here.
Twitter Reverse Auth
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