[twitter-dev] Passing OAuth Access Key/Secrets between Our Mobile Web Apps?

2010-05-12 Thread tsmango
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


Re: [twitter-dev] Passing OAuth Access Key/Secrets between Our Mobile Web Apps?

2010-05-12 Thread Taylor Singletary
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