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, Twitter http://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 >