Thanks for the quick reply! It will definitely be obvious that the
iPhone app and the web application go hand in hand and we will always
use the non-xAuth flow in the web application. Otherwise thank you for
the suggestion about additionally signing requests coming from the
iPhone application. I'll be sure to work that out. Being able to pass
the access key/secrets to identify the user will be a huge help.
On May 12, 3:26 pm, Taylor Singletary <taylorsinglet...@twitter.com>
> There's really not much concern about this, Thomas, as long as the consumer
> keys and secrets remain secure and are never transmitted over the wire. The
> caveat here is just not to surprise your users -- if they distinctly think
> of the twitter integration in your web application and your mobile
> application as two separate, distinct things, then they may be a bit
> surprised when the web application already knows about Twitter and
> vice-versa. But it would seem in the description you provide below that this
> is likely not a concern and would best serve your users.
> As long as you continue using the non-xAuth flow in your web application,
> you should be on the good side of the law. I would recommend that you
> implement a signing mechanism of some sort between your iPhone app and your
> web server as well so that you can be assured that when you receive an
> access token from outside, it in fact came from your iPhone application and
> not some other party.
> Taylor Singletary
> Developer Advocate, Twitterhttp://twitter.com/episod
> On Wed, May 12, 2010 at 12:12 PM, tsmango <tsma...@gmail.com> wrote:
> > I'd like to run something past everyone to make sure I'm not missing
> > something obvious that would make what I'm thinking of doing insecure.
> > I'm working on a web application with an iPhone app that goes along
> > with it (we haven't launched yet). Our web application provides an API
> > that the iPhone application uses.
> > Our iPhone application is approved for and successfully using xAuth
> > for signing users in. Once xAuth comes back, the iPhone application
> > only stores the OAuth key/secret pair for the user. Our web
> > application is only using standard OAuth for signing in - it doesn't
> > accept usernames and passwords directly from users.
> > I'd like to offer a simple and secure way for the iPhone application
> > to not only authorize itself with our API, but identify the user
> > making the request.
> > Would it be wrong or insecure for the iPhone application to pass along
> > the access key and access secret for the user on each API call to our
> > web application? This would sufficiently identify the user and, if I'm
> > understanding correctly, wouldn't be able to be used by anyone if
> > intercepted because they wouldn't have our application's consumer key/
> > secret.
> > Again, I could very well be missing something here in terms of how
> > secure this approach would be, that's why I'm asking first. I
> > appreciate any feedback on this plan. Thank you, in advance.
> > --
> > Thomas Mango