Is OAuth Echo right for my project? (Web API + iOS/Android integration question)


#1

Hello and thanks for reading, I’m working on a project that involves a front-end app (both on Android and iOS) that needs to interface with our web-based API to support several key features. I’m trying to decide whether or not OAuth echo will support the features I need, or if the 3-legged auth or sign in with Twitter flows would be more appropriate. Any input from those with experience would be greatly appreciated!

Here is an outline of our Twitter-related needs:
-We want to support sign in with Twitter, so that if the user has never used our service before we can generate a new account for them on our servers based on their user data from GET account/verify_credentials (after they grant our app access of course).
-We want to support posting to several social networks, obviously including Twitter. To simplify things for the guys working on the mobile apps, the plan is to have just one “post update” API endpoint, which can be used to post to any combination of our supported social networks in one API call (depending on which social network access tokens are provided in the POST). Posts may include an image.
-Ideally, we’d like as much of the authentication and interaction with social network APIs (including Twitter’s) as possible to occur on the server side, not the mobile app (this is why I’m considering OAuth echo). In a perfect world the mobile device would never need to touch Twitter’s (or any other social networks) API at all, all communication to social APIs would be routed through our own custom API (a PHP solution using Amazon’s Elastic Beanstalk), so that we can keep tabs on how people are using our app and keep API code from multiple various social networks away from the mobile side of our product. I realize that’s probably not completely practical though, and it may be a security concern in some cases so certain actions must take place on the mobile side.

So…
-For sign in, I think the flow for a new user would look like this:
–User hits ‘sign in with Twitter’ button on the mobile app
–This triggers our API to communicate with Twitter and obtain a request token
–The request token obtained from Twitter is transmitted back to the mobile app
–Using this request token, the mobile device displays Twitter’s ‘authenticate app’ page in a web view in our app
–Assuming success, the mobile app gets back the request token and request token verifier
–Mobile app uses POST oauth/access_token to convert request token to an access token
–Using the access token and GET account/verify_credentials, create a new user on our service
–The access token and secret are stored on the mobile device for later use in making posts etc…

Am I understanding all this correctly? I think I’m on the right track but it would be great if someone with more experience could confirm for me. If we store the access token and secret on the mobile device, is it considered secure to transmit the two values to our custom API each time a user would like to make a post from our app? (We’ll be using https and ssl) I’m guessing that it is not good practice to persist these access token values on our servers? Again, we’d like as little interfacing with social APIs as possible on the mobile app, and would prefer to do all request authorizing and social API interaction from the server side.

Thanks for reading my super long post, hopefully I’ve provided all the necessary info but I can answer any questions if needed. Have a great day!