[oauth] Affinity between access tokens and consumer identity
I had a question on OAuth version 1.0a that I’m hoping you could help me find an answer to: It looks like to me that in the spec there is no requirement for some affinity between the Consumer Key/Consumer Secret, and the Access token. So here’s the scenario: for some services, Consumer may choose to store/cache the Access Token for a duration of time which sometimes can be infinite (for instance if user gives consent for Service X to access his/her Netflix queue, Service X does not want to keep asking user to give consent every time, so will store the Access token and uses it any time user comes back till it expires which in some cases doesn’t) Now let’s say a hard drive containing all these tokens is stolen, etc. And I get a hold of it. What prevents me from becoming a partner with Netflix and use Service X's stored Access tokens with my own Consumer Key and Secret to read users’ protected data? In other words it seems to me that the identity of the consumer is not required to be tied to Access Tokens explicitly in the spec, is that the case? (I guess another example is what if service provider wants to revoke all access keys issued to a specific consumer) Is this something that is considered out of scope? Thanks in advance! -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] 2-legged OAuth -- why it's great, what it's missing
Here's my view of why 2-legged OAuth (which isn't really OAuth) is such a handy tool to have for a system already using OAuth. Here are some problems that 2-legged OAuth does *not* have, and a list of other solutions that do (each assumes best possible implementation on both ends). - the user's password is exposed to a MITM - http basic - API Key - hassle configuring apache or other layers -- (with OAuth, all authentication is in the application code and storage) - http basic - http digest - HTTPS - a MITM interceptor can acquire information that can be used to impersonate the user - http basic - http digest - API Key - HTTPS (when exploited by obscure circumstances such as DNS compromise or unsophisticated user) - non-standard implementation without community security vetting - API Key + API Secret (or other signing-with-secret solution) The best non-oauth solution, security-wise, is a secret-signed request + HTTPS. The only thing OAuth misses from this solution is content encryption. HTTPS can be used alongside OAuth, making it the overall superior solution. So, first of all, what do others think of my description of the space above? Second, here is what 2-legged OAuth is missing from the spirit of OAuth: In three-legged OAuth, the user can revoke the third-party's access to their resources at any time, if they stop trusting the third-party. In two-legged OAuth, if the service fears that they credentials have been compromised, they can change them, but -- if I'm not mistaken -- this results in all of the user tokens being invalidated as well, even though the compromised service creds wouldn't necessarily have results in access to the user creds or resources. In other words: users revoking their OAuth keys for a service does not have annoying side-effects, but a service changing its credentials DOES. I realize that this wasn't one of the goals of OAuth, and on a service-by-service basis it seems reasonable for the onus of security and data-management to be -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Re: 2-legged OAuth -- why it's great, what it's missing
On Sat, Jan 30, 2010 at 5:32 PM, John Joseph Bachir johnjosephbac...@gmail.com wrote: I realize that this wasn't one of the goals of OAuth, and on a service-by-service basis it seems reasonable for the onus of security and data-management to be Hit the save button too soon on that -- was just going to close by saying, its the service's responsibility to manage their credentials, and having to change credentials is a rare occurrence -- but I just wanted to stir up a little discussion. Cheers, John -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
[oauth] Re: 2-legged OAuth -- why it's great, what it's missing
In theory, a service provider could handle a change of consumer credentials, and continue to accept access tokens that it issued to that consumer previously. But that seems dangerous. If the consumer credentials were revealed to an attacker, it seems likely that access tokens and secrets were also revealed. I assume we're talking about http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html or something similar. On Jan 30, 3:32 pm, John Joseph Bachir johnjosephbac...@gmail.com wrote: Second, here is what 2-legged OAuth is missing from the spirit of OAuth: In three-legged OAuth, the user can revoke the third-party's access to their resources at any time, if they stop trusting the third-party. In two-legged OAuth, if the service fears that they credentials have been compromised, they can change them, but -- if I'm not mistaken -- this results in all of the user tokens being invalidated as well, even though the compromised service creds wouldn't necessarily have results in access to the user creds or resources. In other words: users revoking their OAuth keys for a service does not have annoying side-effects, but a service changing its credentials DOES. -- You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
