[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
OAuth is complex. Witness last weeks crazy rush to fix something that was visible in the protocol all along. But no one saw it ... most likely because of protocol complexity. Seeing as Kent's confessions are mostly around signature: it's odd that an authorization protocol needs to specify signature mechanisms ... at all. The end result of an OAuth protocol flow is: * some state on the provider, and * some manifestation of this state on the consumer, who uses this to authenticate the provider when accessing the resource. An authz protocol should encompass how to clearly describe resources, operations, and parties authorized. To do that you really need no other info than URLs and operations. There is no need to bounce this information via the consumer: * The consumer performs an operation on a resource, and * The provider checks to see whether the consumer is allowed. The manner in which the provider authenticates the consumer should be completely independent from the authorization protocol. Forcing any style of authentication is a bit draconian. (A token is tied to a secret for authentication) There are also other issues with baking this all into one protocol. For example, only the provider has to be the one issuing and consuming tokens. This format is opaque. This means I cannot issue my own authorizations -- ahead of time if I wants -- nor can I move them around providers... For some reason OAuth came out as a bit of a REST anti-pattern. Access to resources now are shrouded inside an odd mix of additional protocol flows and signature mechanisms. With non-easily addressable consumers (like desktop apps) you run into the turtles all the way down problem when introducing authentication inside an authorization protocol: you can issue secrets and tokens to an app, or try one of the n-legged approaches, but they fail as you never can be sure who or what you're ultimately authenticating. I'm probably rambling a bit, just some thoughts, Hans On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina chris.mess...@gmail.com wrote: Is OAuth this hard for everyone else? http://kentbrewster.com/oauth-confessions/ *Sniff*. Chris -- Chris Messina Open Web Advocate factoryjoe.com // diso-project.org // openid.net // vidoop.com This email is: [ ] bloggable [X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: CANCELLED: San Francisco meetup this Tuesday 5pm
:( Seems like 5 people would be a good-sized group to actually get some real work done. Of course it's up to you and then folks who had signed up to attend, but I wouldn't be discouraged by what might appear to be a relatively small sized number of attendees. Chris On Mon, Apr 27, 2009 at 2:04 PM, Leah Culver leah.cul...@gmail.com wrote: Since less than 5 people have responded, I'm cancelling this meeting. Sorry about the short notice, Leah On Fri, Apr 24, 2009 at 2:42 PM, Leah Culver leah.cul...@gmail.comwrote: Hi all, My eyes hurt from trying to read long email threads. There's quite a few good ideas for helping protect against the current security issue and it will be helpful to get together to discuss. Here's the details: OAuth Meetup Tuesday, Apr 28th at 5pm Six Apart 548 4th Street I'll try to get the conference call stuff working too - more about this later. Sorry for the short notice! I'll try to summarize the meeting and get the notes back in the mailing list or wiki. Leah -- Chris Messina Open Web Advocate factoryjoe.com // diso-project.org // openid.net // vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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] How should I distinguish between approved or denied authorization?
Section 6.2.3 of the spec says: If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. How does one typically indicate, in the authorization callback, whether the Request Token was approved or denied? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina chris.mess...@gmail.com wrote: Is OAuth this hard for everyone else? http://kentbrewster.com/oauth-confessions/ I think that we agree that OAuth *is* complex, and has a few hard points (specially about the signing process e.g. the signature base string composition) but if we think at what it's trying to do (passing authorization around in a three subjects dance across untrusted channels) that's understandable. These are the things that have helped me (might be banal, might be not...): - read the spec, try to understand the steps, - look at the examples and walkthroughs (specially those at hueniverse.com ) - look at the examples from the library of your choice (the ruby one in my case) - try out with the test providers - read the mailing list Luca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
On Tue, Apr 28, 2009 at 9:20 AM, Chris Messina chris.mess...@gmail.com wrote: Thanks Luca, Let me ask this: what else could we be doing to make the walk up experience of OAuth easier/better? I'd start from the action points here: http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/ And It'd be great to see (on OAuth.net) an illustrated OAuth spec (I found this http://bit.ly/2j5qT very helpful in understanding the OAuth attack) Luca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
Hi Chris, Luca's list is good. Maybe you can add a section how someone could start implementing OAuth in his software. And start the section with a small list like Luca's. Maybe you can add a warning about the problems with url encoding in different programming languages. And supply correct versions. I like to add that whenever you implement a protocol you have to read the spec first, or at least a good summary of the spec. The moment you understand the protocol (and also the spec) you can start implementing it. Whilst implementing it you add test cases so that you can validate your implementation. That is before you start using the protocol to talk to an external party. From Kent Brewster's comments I think he didn't read the spec before he started trying to implement OAuth. He also clearly didn't try out the published test cases. My impression is that he didn't have a full understanding of the OAuth protocol before implementing it. Programming any protocol, especially security related protocols, is careful work. You need to know what you are doing. You need to grow your software by testing. You need to understand the protocol thoroughly. That is why programmers use libraries for most protocols. As protocols go, OAuth is not that hard to implement. Testing it in a live situation is hard though, mostly due to the omission of sensible error messages. What could help OAuth is a better standardization of the error message returned. Errors like nonce reuse can then be easily caught and reported. - Marc On 28 apr 2009, at 09:20, Chris Messina wrote: Thanks Luca, Let me ask this: what else could we be doing to make the walk up experience of OAuth easier/better? I think that the website needs an overhaul (as do most of the Open/ Social Stack sites!!). I'd like to know what we could do to make these sites better — meeting a wider community of practice's needs. Chris On Tue, Apr 28, 2009 at 12:13 AM, Luca Mearelli luca.meare...@gmail.com wrote: On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina chris.mess...@gmail.com wrote: Is OAuth this hard for everyone else? http://kentbrewster.com/oauth-confessions/ I think that we agree that OAuth *is* complex, and has a few hard points (specially about the signing process e.g. the signature base string composition) but if we think at what it's trying to do (passing authorization around in a three subjects dance across untrusted channels) that's understandable. These are the things that have helped me (might be banal, might be not...): - read the spec, try to understand the steps, - look at the examples and walkthroughs (specially those at hueniverse.com ) - look at the examples from the library of your choice (the ruby one in my case) - try out with the test providers - read the mailing list Luca -- Chris Messina Open Web Advocate factoryjoe.com // diso-project.org // openid.net // vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: How should I distinguish between approved or denied authorization?
I think you send a 401 error... http://lmgtfy.com/?q=Error+401 On Apr 27, 11:42 pm, mdub mdu...@gmail.com wrote: Section 6.2.3 of the spec says: If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. How does one typically indicate, in the authorization callback, whether the Request Token was approved or denied? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On 4/28/09 12:33 AM, Josh Roesslein wrote: Couldn't we verify the user on the consumer-side during the callback URL redirect (user returning from SP after authorization)? This callback URL has two pieces of data: - Callback secrete: generated by SP after user authorizes consumer - Request token: publicly known, so could be forged by attacker If and only if the callback URL is protected from tampering. Since we cannot guarantee the consumer secret and request token secret to be ... well, secret ... there's no way to guarantee in ALL cases that the callback URL will be protected from tampering. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 1:18 PM, Dossy Shiobara do...@panoptic.com wrote: If and only if the callback URL is protected from tampering. Since we cannot guarantee the consumer secret and request token secret to be ... well, secret ... there's no way to guarantee in ALL cases that the callback URL will be protected from tampering. If you can't guarantee the request token secret to be secret, then all bets are off everywhere. OAuth has been designed such that the request token secret *is* secret, and in the case of non-redistributed consumers (e.g., web sites or open source software with a requirement to obtain a new consumer key/secret), the consumer secret *is* also secret. For the callback URL signing case, it is absolutely possible to guarantee that the request token secret remains private, and therefore absolutely possible to ensure that the callback URL (and thus, the verification token) is genuine. My reading of Eran's proposal doesn't incorporate this level of signing. That is, I *don't* see a proposal to actually include a callback signature parameter in the callback URL, as in: http://example.com/callbackEndpoint?oauth_token=xoauth_verifier=yoauth_signature=HMAC-SHA1(oauth_token_secret, Normalized(http://example.com/callbackEndpoint?oauth_token=xoauth_verifier=y;)) It might be worthwhile, though, to do that? On the other hand, it would significantly complicate things, and might not provide a significant benefit, especially if both the callback URL and the authorization endpoint were handled over SSL. b. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
On 4/28/09 1:42 AM, Chris Messina wrote: Is OAuth this hard for everyone else? http://kentbrewster.com/oauth-confessions/ *Sniff*. Funny enough, I ran into at least a few of the items on his list when writing my own OAuth consumer implementation from scratch. I honestly think that the OAuth _design_ isn't what makes it difficult. It's the way the specification is written. What really bit me in the ass the hardest was the Parameter Encoding requirement of the signature when using HTTP header authentication. Deviating from the RFC just for OAuth violates POLS, guys. Honestly, after trying to decipher the spec. and not getting very far, I put it aside and went to Eran's GUI: http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html I almost wish I'd not bothered to confuse myself with the spec. and just used that one page. It's a _fantastic_ reference implementation for anyone developing their own OAuth consumer. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Are those off the table? I think (3), although potentially difficult to deploy, would significantly help. Maybe (3) and (4) could be added in the spec as Best Practice or Recommendations? Hubert On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Let's see if we can take a quick break from the discussion and get a sense of where we are. Please answer the questions to follow. --- We have identified 2 solutions listed here: https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory * Signed Approval URLs This proposal breaks the protocol into two separate flows, one for Consumers capable of launching a browser and accepting callbacks, and another for those who can't. It requires a significant rewrite of the specification because of the way the flow and signature are mixed together in the current Core 1.0 specification. * Signed Callback URLs This proposal makes the callback URL part of the signed request for Request Token (which does not allow an attacker to manipulate it), and adds some unpredictable value to the callback redirection that is needed to get an Access Token. The spec changes include (see quick reference at the bottom): - Move the oauth_callback parameter from 6.2.1 to 6.1.1 - Add a new parameter to 6.2.3 which is needed to make 6.3.1 --- Open questions: 1. Am I missing a completely different alternative? If yes, please create a new wiki page and point to it (if you don't have access ask or email it to someone who does). 2. Given the simplicity of the Signed Callback URLs *specification change*, I would like to instead of asking people which solution they prefer, to ask people if they have a strong objection to using the Signed Callback URLs solution, and if so, to explain why? 3. For the Signed Callback URLs solution, what to call the new parameter returned in 6.2.3? Suggestions so far included: - pin - verifier - chaperon - callback token - callback secret 4. And, should the new parameter be added to 6.3.1 (oauth_token + oauth_something) or replace the value of the oauth_token parameter? The second option basically returns an authorized token which is used with the existing secret from 6.1.2. The benefit of a new parameter is it is easier to follow the protocol. The benefit of reusing oauth_token to make 6.3.1 is that is keeps the signed request consistent with all other signed requests (no new parameters). EHL --- Quick Reference 6.1.1. Consumer Obtains a Request Token 6.1.2. Service Provider Issues an Unauthorized Request Token 6.2.1. Consumer Directs the User to the Service Provider 6.2.2. Service Provider Authenticates the User and Obtains Consent 6.2.3. Service Provider Directs the User Back to the Consumer 6.3.1. Consumer Requests an Access Token 6.3.2. Service Provider Grants an Access Token --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong hubert...@gmail.com wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Actually, there is no requirement that the Consumer have any notion of identity, in which case the consumer has no mechanism to sign user in. The idea here is that you can leverage the the SP's authentication service as long as you can verify that the u...@sp == u...@consumer. And the only way to do that is w/ an out-of-band agreement, such as a PIN that the user gets upon sign-in at the SP and must type in at the consumer. --peter Are those off the table? I think (3), although potentially difficult to deploy, would significantly help. Maybe (3) and (4) could be added in the spec as Best Practice or Recommendations? Hubert On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Let's see if we can take a quick break from the discussion and get a sense of where we are. Please answer the questions to follow. --- We have identified 2 solutions listed here: https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory * Signed Approval URLs This proposal breaks the protocol into two separate flows, one for Consumers capable of launching a browser and accepting callbacks, and another for those who can't. It requires a significant rewrite of the specification because of the way the flow and signature are mixed together in the current Core 1.0 specification. * Signed Callback URLs This proposal makes the callback URL part of the signed request for Request Token (which does not allow an attacker to manipulate it), and adds some unpredictable value to the callback redirection that is needed to get an Access Token. The spec changes include (see quick reference at the bottom): - Move the oauth_callback parameter from 6.2.1 to 6.1.1 - Add a new parameter to 6.2.3 which is needed to make 6.3.1 --- Open questions: 1. Am I missing a completely different alternative? If yes, please create a new wiki page and point to it (if you don't have access ask or email it to someone who does). 2. Given the simplicity of the Signed Callback URLs *specification change*, I would like to instead of asking people which solution they prefer, to ask people if they have a strong objection to using the Signed Callback URLs solution, and if so, to explain why? 3. For the Signed Callback URLs solution, what to call the new parameter returned in 6.2.3? Suggestions so far included: - pin - verifier - chaperon - callback token - callback secret 4. And, should the new parameter be added to 6.3.1 (oauth_token + oauth_something) or replace the value of the oauth_token parameter? The second option basically returns an authorized token which is used with the existing secret from 6.1.2. The benefit of a new parameter is it is easier to follow the protocol. The benefit of reusing oauth_token to make 6.3.1 is that is keeps the signed request consistent with all other signed requests (no new parameters). EHL --- Quick Reference 6.1.1. Consumer Obtains a Request Token 6.1.2. Service Provider Issues an Unauthorized Request Token 6.2.1. Consumer Directs the User to the Service Provider 6.2.2. Service Provider Authenticates the User and Obtains Consent 6.2.3. Service Provider Directs the User Back to the Consumer 6.3.1. Consumer Requests an Access Token 6.3.2. Service Provider Grants an Access Token --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 7:37 AM, Blaine Cook rom...@gmail.com wrote: On Tue, Apr 28, 2009 at 1:18 PM, Dossy Shiobara do...@panoptic.com wrote: If and only if the callback URL is protected from tampering. Since we cannot guarantee the consumer secret and request token secret to be ... well, secret ... there's no way to guarantee in ALL cases that the callback URL will be protected from tampering. If you can't guarantee the request token secret to be secret, then all bets are off everywhere. OAuth has been designed such that the request token secret *is* secret, and in the case of non-redistributed consumers (e.g., web sites or open source software with a requirement to obtain a new consumer key/secret), the consumer secret *is* also secret. That's exactly right: OAuth leverages the secrecy of the out-of-band agreement between consumer and SP. The request token is built upon that assumption, so it can safely be considered secret for the purposes of OAuth. For the callback URL signing case, it is absolutely possible to guarantee that the request token secret remains private, and therefore absolutely possible to ensure that the callback URL (and thus, the verification token) is genuine. While it is possible to tweak things to make sure the callback URL is genuine, that does not directly address the need to verify that the u...@consumer == u...@sp. Of course, it makes it highly probable and also makes an attack less likely (actually makes the attack in question impossible), but you are still relying on stateless HTTP transactions to establish state between SP consumer user. The only way I can see to accomplish that is to create out-of-band state on the user (e.g., a PIN or somesuch) that they carry from SP to consumer. --peter My reading of Eran's proposal doesn't incorporate this level of signing. That is, I *don't* see a proposal to actually include a callback signature parameter in the callback URL, as in: http://example.com/callbackEndpoint?oauth_token=xoauth_verifier=yoauth_signature=HMAC-SHA1(oauth_token_secret, Normalized(http://example.com/callbackEndpoint?oauth_token=xoauth_verifier=y;)) It might be worthwhile, though, to do that? On the other hand, it would significantly complicate things, and might not provide a significant benefit, especially if both the callback URL and the authorization endpoint were handled over SSL. b. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 2:57 PM, Peter Keane pjke...@gmail.com wrote: On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong hubert...@gmail.com wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Actually, there is no requirement that the Consumer have any notion of identity, in which case the consumer has no mechanism to sign user in. The idea here is that you can leverage the the SP's authentication service as long as you can verify that the u...@sp == u...@consumer. And the only way to do that is w/ an out-of-band agreement, such as a PIN that the user gets upon sign-in at the SP and must type in at the consumer. So if I understand your use case, in addition to delegated authorization of Consumer to access a resource at SP, OAuth also provides for delegated authentication of the user at the Consumer by the SP? Just trying to get my head around that case... Hubert --peter Are those off the table? I think (3), although potentially difficult to deploy, would significantly help. Maybe (3) and (4) could be added in the spec as Best Practice or Recommendations? Hubert On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Let's see if we can take a quick break from the discussion and get a sense of where we are. Please answer the questions to follow. --- We have identified 2 solutions listed here: https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory * Signed Approval URLs This proposal breaks the protocol into two separate flows, one for Consumers capable of launching a browser and accepting callbacks, and another for those who can't. It requires a significant rewrite of the specification because of the way the flow and signature are mixed together in the current Core 1.0 specification. * Signed Callback URLs This proposal makes the callback URL part of the signed request for Request Token (which does not allow an attacker to manipulate it), and adds some unpredictable value to the callback redirection that is needed to get an Access Token. The spec changes include (see quick reference at the bottom): - Move the oauth_callback parameter from 6.2.1 to 6.1.1 - Add a new parameter to 6.2.3 which is needed to make 6.3.1 --- Open questions: 1. Am I missing a completely different alternative? If yes, please create a new wiki page and point to it (if you don't have access ask or email it to someone who does). 2. Given the simplicity of the Signed Callback URLs *specification change*, I would like to instead of asking people which solution they prefer, to ask people if they have a strong objection to using the Signed Callback URLs solution, and if so, to explain why? 3. For the Signed Callback URLs solution, what to call the new parameter returned in 6.2.3? Suggestions so far included: - pin - verifier - chaperon - callback token - callback secret 4. And, should the new parameter be added to 6.3.1 (oauth_token + oauth_something) or replace the value of the oauth_token parameter? The second option basically returns an authorized token which is used with the existing secret from 6.1.2. The benefit of a new parameter is it is easier to follow the protocol. The benefit of reusing oauth_token to make 6.3.1 is that is keeps the signed request consistent with all other signed requests (no new parameters). EHL --- Quick Reference 6.1.1. Consumer Obtains a Request Token 6.1.2. Service Provider Issues an Unauthorized Request Token 6.2.1. Consumer Directs the User to the Service Provider 6.2.2. Service Provider Authenticates the User and Obtains Consent 6.2.3. Service Provider Directs the User Back to the Consumer 6.3.1. Consumer Requests an Access Token 6.3.2. Service Provider Grants an Access Token --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Mon, Apr 27, 2009 at 11:33 PM, Josh Roesslein jroessl...@gmail.com wrote: Peter, Couldn't we verify the user on the consumer-side during the callback URL redirect (user returning from SP after authorization)? This callback URL has two pieces of data: - Callback secrete: generated by SP after user authorizes consumer - Request token: publicly known, so could be forged by attacker Plus we can do this callback with https to prevent man in the middle attacks on the wire. We are using https to exchanges passwords with the SP, so if https was vulnerable in some way, we have already lost the fight since the attacker now has our SP password. As long as the consumer links this authorization with the user during this callback phase, the attack can not do a session fixation. When consumer goes to fetch access token, it can only do so with the request token and the callback secrete. Since only the authorizing user can know this callback secrete, an attacker can not complete this callback phase. Consumers should NOT bind request tokens to accounts. This should only be done during callback. This way even if the attacker generated the request token URL using their consumer account, it is not bound to any account yet. This only occurs during the callback phase which only the user can do. I think this provider a verifiable means to link the user's consumer account with their SP account with out having to do any pin exchanges. We could do a manual exchange of the callback secrete (so its like a pin) that the user manually enters into the consumer. This way there is no way a man in the middle can see this value. Consumer will know this is the right user when it fetches the access token (which will fail with invalid value) and the SP will know its valid since the incoming value from the consumer matches what it gave to the user. A social attack could be used to make user share this value. With proper education we can help minimize this, but not totally prevent it. This is why I don't like the pin approach, it leaves it opens us up for another social attack. By invisibly passing this value via a https callback, a social attack is blocked. Hi Josh- All of the strong/secure parts of the OAuth spec are built on previous arrangements (out-of-band): the consumer-SP registration, and the SP user authentication mechanism. Both of those are vulnerable to social attacks, but those are out of scope for OAuth (and should be). You are correct that a manual exchange of callback secrete provides the verifibility that we need. I don't think a social attack is likely, either, since that secret is only created upon user authentication at the SP (i.e., too late in the game for the attacker to get at it). Of course, it should be a once-and-only-once validity and for a limited time period, but it does ensure verifiable identity. --peter On Mon, Apr 27, 2009 at 10:25 PM, pkeane pjke...@gmail.com wrote: On Apr 27, 10:11 am, Brian Eaton bea...@google.com wrote: On Sun, Apr 26, 2009 at 6:29 PM, Peter Keane pjke...@gmail.com wrote: b) that's what the unpredictable callback token is for. Does that demonstrate it is the same user? I believe it makes it highly likely, but not verifyable (in standard authentication terms. Nothing is 100% verifyable). The request token provides linkage from the consumer to the service provider. The callback token provides linkage in the opposite direction. If the consumer proves possession of a matching request token and callback token, that's excellent evidence that no session fixation attack is occurring. Hi Brian- Certainly, it is excellent evidence. But I worry about not having a verifiable linkage. The linkages that OAuth leverage are as follows: 1. The consumer and the SP have a shared out-of-band secret (consumer pre-registration). That allows the consumer to tell the SP hey it's verifiably me (by way of the request token). 2. The user and the SP also have a shared out-of-band arrangement -- SP authentication -- that verifies the user is verifiably who they say they are. Note that those are both based on out-of-band arrangements. There is actually no link to tie the user to the consumer, except for tokens, parameters, etc., but those are all in-band and so are *not* verifiable. That last missing link is necessary for verifiable identification of the u...@consumer. A simple PIN or somesuch would do it. I'm happy with OAuth for the typical sorts of social networking, photo-sharing, etc. use cases, and I use it for that. But I'd very much like to be able recommend it for more highly secure scenarios here on campus (I work in higher ed) that might involve confidential records. For OAuth to replace or be used in conjunction with the cuurent campus SSO and federated systems like Shibboleth, we would really need that extra level of verifiable security. --peter
[oauth] Re: Moving forward
On Tue, Apr 28, 2009 at 8:14 AM, Hubert Le Van Gong hubert...@gmail.com wrote: On Tue, Apr 28, 2009 at 2:57 PM, Peter Keane pjke...@gmail.com wrote: On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong hubert...@gmail.com wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Actually, there is no requirement that the Consumer have any notion of identity, in which case the consumer has no mechanism to sign user in. The idea here is that you can leverage the the SP's authentication service as long as you can verify that the u...@sp == u...@consumer. And the only way to do that is w/ an out-of-band agreement, such as a PIN that the user gets upon sign-in at the SP and must type in at the consumer. So if I understand your use case, in addition to delegated authorization of Consumer to access a resource at SP, OAuth also provides for delegated authentication of the user at the Consumer by the SP? Yes, that's right. What it does (for the sake of the SP) is assert this user on the consumer is indeed the same user that authenticated at the SP. Authorization always requires authentication (system needs to know who it is authorizing). As an analogy, imagine if banks allowed withdrawals w/o a user typing a PIN. The bank can guarantee that I am the one who was issued the card AND it can guarantee that is the same card being used to withdraw money. And you can do all kinds of things to guard against anyone but the legitimate card owner to get ahold of it. But unless you take that extra step (the PIN entered at the ATM) you never create sufficiant linkages to verify authenticity. That's why PIN can be short easy to remember (but should NOT be written on the card! ;-)). Since it is an out-of-band arrangement, it offers a high level of assurance. --peter Just trying to get my head around that case... Hubert --peter Are those off the table? I think (3), although potentially difficult to deploy, would significantly help. Maybe (3) and (4) could be added in the spec as Best Practice or Recommendations? Hubert On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Let's see if we can take a quick break from the discussion and get a sense of where we are. Please answer the questions to follow. --- We have identified 2 solutions listed here: https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory * Signed Approval URLs This proposal breaks the protocol into two separate flows, one for Consumers capable of launching a browser and accepting callbacks, and another for those who can't. It requires a significant rewrite of the specification because of the way the flow and signature are mixed together in the current Core 1.0 specification. * Signed Callback URLs This proposal makes the callback URL part of the signed request for Request Token (which does not allow an attacker to manipulate it), and adds some unpredictable value to the callback redirection that is needed to get an Access Token. The spec changes include (see quick reference at the bottom): - Move the oauth_callback parameter from 6.2.1 to 6.1.1 - Add a new parameter to 6.2.3 which is needed to make 6.3.1 --- Open questions: 1. Am I missing a completely different alternative? If yes, please create a new wiki page and point to it (if you don't have access ask or email it to someone who does). 2. Given the simplicity of the Signed Callback URLs *specification change*, I would like to instead of asking people which solution they prefer, to ask people if they have a strong objection to using the Signed Callback URLs solution, and if so, to explain why? 3. For the Signed Callback URLs solution, what to call the new parameter returned in 6.2.3? Suggestions so far included: - pin - verifier - chaperon - callback token - callback secret 4. And, should the new parameter be added to 6.3.1 (oauth_token + oauth_something) or replace the value of the oauth_token parameter? The second option basically returns an authorized token which is used with the existing secret from 6.1.2. The benefit of a new parameter is it is easier to follow the protocol. The benefit of reusing oauth_token to make 6.3.1 is that is keeps the signed request consistent with all other signed requests (no new parameters). EHL --- Quick Reference 6.1.1. Consumer Obtains a Request Token 6.1.2. Service Provider Issues an Unauthorized Request Token 6.2.1. Consumer Directs the User to the Service Provider 6.2.2. Service Provider Authenticates the User and Obtains Consent 6.2.3. Service Provider Directs the User Back to the Consumer 6.3.1. Consumer Requests an Access Token 6.3.2. Service Provider Grants an Access Token
[oauth] Re: Moving forward
On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane pjke...@gmail.com wrote:
Yes, that's right. What it does (for the sake of the SP) is assert
this user on the consumer is indeed the same user that authenticated
at the SP. Authorization always requires authentication (system
needs to know who it is authorizing).
For OAuth, this relationship is simple. The SP authenticates the user,
but authorizes the consumer-plus-request-token pair. The SP *does not*
authorize an authenticated user at the consumer end. That relationship
is up to the consumer to decide.
Put another way, if TweetCash had been given authorization by many
users to access Twitter accounts, they (TweetCash) could impersonate
any one of those accounts in any way they choose. However, it's a
trust relationship. If TweetCash were to abuse that trust, then
Twitter has the ability to disable their access wholesale (via the
consumer key) or the users have the ability to revoke access on a
case-by-case bases. At no point can Twitter *guarantee* that TweetCash
isn't abusing the trust, but it's probably impossible to do so without
creating an unusable technology, particularly for the sorts of
problems we're trying to solve.
The exploit that we're dealing with is that the consumer has no way to
ensure that the SP has authorized access to the intended party. The
verification token *does* ensure this, since it guarantees that the
person that clicks Authorize {consumer} is the same one that is
interacting with the consumer, and that's all we're trying to solve.
OAuth does not, and should not, attempt to authenticate identity
across sites.
b.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
OAuth group.
To post to this group, send email to oauth@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: Moving forward
On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Requiring the user authenticate to the Consumer doesn't prevent the attack, as the attacker is a legitimate user of Consumer in the attack scenario. What I keep proposing is that the user must authenticate at the _Provider_ before the request token request. This would completely eliminate the attack in the scenario. And yes, making request tokens one-time only is a MUST, IMHO. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 9:32 AM, Dossy Shiobara do...@panoptic.com wrote: On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Requiring the user authenticate to the Consumer doesn't prevent the attack, as the attacker is a legitimate user of Consumer in the attack scenario. What I keep proposing is that the user must authenticate at the _Provider_ before the request token request. This would completely eliminate the attack in the scenario. Hi Dossy- But the consumer will still need to communicate back to the SP that it has some unique knowledge that it could only have been offered at the SP authentication point. Most proposals do this with the verification token -- my reasoning leads me to believe that needs to be passed out-of-band. I'm not sure that moving the authentication before request token necessarilly guarantees that. --peter And yes, making request tokens one-time only is a MUST, IMHO. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 4:32 PM, Dossy Shiobara do...@panoptic.com wrote: On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Requiring the user authenticate to the Consumer doesn't prevent the attack, as the attacker is a legitimate user of Consumer in the attack scenario. What I keep proposing is that the user must authenticate at the _Provider_ before the request token request. This would completely eliminate the attack in the scenario. And yes, making request tokens one-time only is a MUST, IMHO. Ah yes, that's what I meant: the user authenticates at the Provider before the token request is issued - sorry, getting old :) Sounds like a valid option to me. Is the reason for *discarding* this solution the fact that it's an additional roundtrip in the flow (or put another way it's too big a change to the current protocol)? Cheers, Hubert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On 4/28/09 9:05 AM, Peter Keane wrote: That's exactly right: OAuth leverages the secrecy of the out-of-band agreement between consumer and SP. The request token is built upon that assumption, so it can safely be considered secret for the purposes of OAuth. If this is the founding principle of OAuth, then perhaps I'm wasting my time. Perhaps I should instead formulate a specification for an open authorization protocol that doesn't have this assumption. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 9:42 AM, Dossy Shiobara do...@panoptic.com wrote: On 4/28/09 9:05 AM, Peter Keane wrote: That's exactly right: OAuth leverages the secrecy of the out-of-band agreement between consumer and SP. The request token is built upon that assumption, so it can safely be considered secret for the purposes of OAuth. If this is the founding principle of OAuth, then perhaps I'm wasting my time. Perhaps I should instead formulate a specification for an open authorization protocol that doesn't have this assumption. Dossy- It's only part of the equation though. The *whole* protocol does not rest on that. Only the part that allows the consumer to authenticate (as it were), with the SP -- essentially saying yes, SP this is indeed the consumer that pre-registered with you. Mixing in the user is where things get tricky --peter -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On 4/28/09 10:40 AM, Peter Keane wrote: But the consumer will still need to communicate back to the SP that it has some unique knowledge that it could only have been offered at the SP authentication point. Most proposals do this with the verification token -- my reasoning leads me to believe that needs to be passed out-of-band. I'm not sure that moving the authentication before request token necessarilly guarantees that. It doens't need to be passed out of band. You only need to defend against it being intercepted by an attacker. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 4:41 PM, Hubert Le Van Gong hubert...@gmail.com wrote: Is the reason for *discarding* this solution the fact that it's an additional roundtrip in the flow (or put another way it's too big a change to the current protocol)? yes and more than that the fact that adding another roundtrip could make for a far worse user experience, possibly alienating a lot of legitimate users pushing them towards even less safe protocols (e.g. giving out their SP user password) Luca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Apr 28, 2009, at 10:32 AM, Dossy Shiobara wrote: On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Requiring the user authenticate to the Consumer doesn't prevent the attack, as the attacker is a legitimate user of Consumer in the attack scenario. Agreed. There are two parts - only one part is about both sides authenticating a user at their sites. The other part is the two parties (consumer and SP) agreeing that they are the same party (for the purposes of the protocol). One possibility is to (as was suggested by Nat) use a Web SSO protocol and base that trust (shared notion of user at both sites) upon: i) Web browser redirect-based protocols like OpenID and SAML ii) Passing an identifier between the consumer and SP, which they can both agree on. These steps are (in my opinion) neither part of standard OAuth itself, nor should they be, _explicitly_, unless we consider that for the purposes of adequate security for delegated authorization, it is required that both consumer and SP have a notion of identity, and can verify the identity of the user adequately (ie. via authentication). And this leaves open what would happen if the two parties don't or can't, a priori, agree on an identifier for the user (ie. if they don't support OpenID, or only support their own OpenIDs. One possibility would be to describe the problem in the security considerations of the specification, and mention that both the consumer and the SP may want to both authenticate the user adequately, and (perhaps even as an extension to the protocol) share an identifier that they could agree on. Making the user type a PIN (I forget who first suggested that) seems another plausible way, that may allow the consumer to avoid the notion of identity while maintaining adequate security. What I keep proposing is that the user must authenticate at the _Provider_ before the request token request. This would completely eliminate the attack in the scenario. As others (Peter, Nat, Hubert at least) have said (and I agree with), either the user must essentially authenticate in _both_ places (perhaps by doing Web SSO between the consumer and SP, where the consumer simply trusts the SP to authenticate the unknown person who showed up at its website because it was done with HTTP redirects, and authenticates the user simply via an authentication assertion from the SP); and those authentications must be connected in some way by the consumer and SP, _or_ a mechanism should be used which allows the SP to indicate a secret to both the consumer and the user, and use the user to connect the authentication at SP with the request token issuance via the PIN. And yes, making request tokens one-time only is a MUST, IMHO. It is certainly a security consideration which should be adequately explained. Regards, - johnk -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
Awesome! Thanks for that. Thanks- - Andy Badera - and...@badera.us - Google me: http://www.google.com/search?q=andrew+badera Sent from Albany, NY, United States On Tue, Apr 28, 2009 at 10:56 AM, Peter Keane pjke...@gmail.com wrote: I can say I would not have gotten very far withoout Google OAuth playground: http://googlecodesamples.com/oauth_playground/ --peter On Tue, Apr 28, 2009 at 9:39 AM, Gilles Devaux gilles.dev...@gmail.com wrote: Agree. OAuth is not that complicated, reading the specs is. But honestly, if you forget to sort the parameters before concatenating it means you haven't read them at all (OAuth 1.0 - 9.1.1). One thing that really helped me to understand the flow was to create a fake Service Provider. --Gilles On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara do...@panoptic.com wrote: On 4/28/09 1:42 AM, Chris Messina wrote: Is OAuth this hard for everyone else? http://kentbrewster.com/oauth-confessions/ *Sniff*. Funny enough, I ran into at least a few of the items on his list when writing my own OAuth consumer implementation from scratch. I honestly think that the OAuth _design_ isn't what makes it difficult. It's the way the specification is written. What really bit me in the ass the hardest was the Parameter Encoding requirement of the signature when using HTTP header authentication. Deviating from the RFC just for OAuth violates POLS, guys. Honestly, after trying to decipher the spec. and not getting very far, I put it aside and went to Eran's GUI: http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html I almost wish I'd not bothered to confuse myself with the spec. and just used that one page. It's a _fantastic_ reference implementation for anyone developing their own OAuth consumer. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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] Apps using OAUTH and REST API in orkut environment
I want to implement REST concept in my application development in orkut environment. Is there any apps that already implemented REST? If yes, How can i do that? I already tried with PHP libraries but no use. It's throwing some errors(fatal errors). I have consumer key and consumer secret but unable to get access token, I am getting http response as you are being redirected to http://www.orkut.com/;. https://www.orkut.com/request_token?oauth_consumer_key=1007220910984 using POST, I am getting response as you are being redirected to http://www.orkut.com/;. Instead it should be oauth_token. How to get opensocial data using OAuth and REST? Kindly help me on this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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] Apps using OAUTH and REST API in orkut environment
I want to implement REST concept in my application development in orkut environment. Is there any apps that already implemented REST and OAUTH? If yes, How can i do that? I already tried with PHP libraries but no use. It's throwing some errors(fatal errors). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Mon, Apr 27, 2009 at 8:25 PM, pkeane pjke...@gmail.com wrote: I'm happy with OAuth for the typical sorts of social networking, photo-sharing, etc. use cases, and I use it for that. But I'd very much like to be able recommend it for more highly secure scenarios here on campus (I work in higher ed) that might involve confidential records. For OAuth to replace or be used in conjunction with the cuurent campus SSO and federated systems like Shibboleth, we would really need that extra level of verifiable security. Hi Peter - SSO systems such as SAML/OpenID/others all use the equivalent of a callback token to bind the session at the identity provider to the relying party. The fix to the OAuth protocol is to make it look just like the campus SSO and federated systems that you mention above: OpenID: signature on authentication response. SAML POST profile: signature on authentication response. SAML artifact profile: random single-use artifact value. All of those systems pass a value that is unpredictable to the attacker to a trusted location at the consumer site. None of those systems force the user to do anything as obnoxious as manually type a pin at the consumer site. If you think manually typing a pin increases security, you should explain the attack you're trying to prevent. Why should OAuth have such a requirement if SAML and OpenID don't? So far the only concrete explanation I've seen is that ATMs require PINs, so OAuth should require a PIN. You're confusing two-factor authentication with federated authentication protocols. Two factor authentication is great, and it's fine for consumers and service providers to implement that. No change to the OAuth protocol is necessary to support it. Again, this is exactly analogous to the situation in OpenID and SAML. It's completely reasonable for a SAML IdP to implement two-factor authentication for their users, and doing so doesn't impact the SAML protocol one whit. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 7:32 AM, Dossy Shiobara do...@panoptic.com wrote: And yes, making request tokens one-time only is a MUST, IMHO. This is a terrible idea for consumers that can't receive callback URLs. For those consumers users are going to have to manually type in a callback token. There will be typos. Under the single use request token proposal, those users will then have to go back through the entire OAuth approval process to get another callback token. It's fine to limit the number of unsuccessful exchange attempts, but a limit of one is too low. Five attempts is more reasonable. Limiting the number of successful exchange attempts to one makes sense. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On 4/28/09 1:40 PM, Brian Eaton wrote: It's fine to limit the number of unsuccessful exchange attempts, but a limit of one is too low. Five attempts is more reasonable. Limiting the number of successful exchange attempts to one makes sense. This makes sense. Perhaps the spec should be organized in this way: The SP MUST invalidate the request token after a successful exchange attempt. The SP MUST invalidate the request token after a certain number of unsuccessful exchange attempts. The number is RECOMMENDED to be between 1 and 5, as appropriate. I don't see why a SP should be prohibited from expiring a token after one unsuccessful exchange attempt. IMHO, the number should be chosen based on the SP's desired security level. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
Hi Brian, On Apr 28, 2009, at 1:36 PM, Brian Eaton wrote: On Mon, Apr 27, 2009 at 8:25 PM, pkeane pjke...@gmail.com wrote: I'm happy with OAuth for the typical sorts of social networking, photo-sharing, etc. use cases, and I use it for that. But I'd very much like to be able recommend it for more highly secure scenarios here on campus (I work in higher ed) that might involve confidential records. For OAuth to replace or be used in conjunction with the cuurent campus SSO and federated systems like Shibboleth, we would really need that extra level of verifiable security. Hi Peter - SSO systems such as SAML/OpenID/others all use the equivalent of a callback token to bind the session at the identity provider to the relying party. The fix to the OAuth protocol is to make it look just like the campus SSO and federated systems that you mention above: OpenID: signature on authentication response. SAML POST profile: signature on authentication response. SAML artifact profile: random single-use artifact value. All of those systems pass a value that is unpredictable to the attacker to a trusted location at the consumer site. None of those systems force the user to do anything as obnoxious as manually type a pin at the consumer site. All of these protocols are for Web-browser based SSO, and establish the trust between the consumer and SP (using the OAuth terminology) by relying on Web-browser technologies (ie. an HTTP redirect sent through the user's browser assures that the browser is the same one at SP as it was at consumer). I do not think the assumptions of OAuth are the same as for those protocols. At least not currently. And I would be wary of going that way without more thought. If you think manually typing a pin increases security, you should explain the attack you're trying to prevent. Why should OAuth have such a requirement if SAML and OpenID don't? I think the security requirement is that you ensure that the entity making a request to the consumer to start the OAuth process is the same entity which is authenticated to the SP. Are you arguing that the callback URL suffices in that regard? Cheers, - johnk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 1:12 PM, Brian Eaton bea...@google.com wrote: For apps that can't receive callback URLs, you need a PIN. Yes we will need to manually pass the callback secrete to the application (aka the pin). I think the solution of signed callbacks w/ a callback secrete adequately closes the security hole while not drastically changing the protocol or the user experience. In fact the user won't even be aware of any of these changes unless the application required the transfer of the pin (the callback secrete). Before all they had to do is notify the application. This solution is quick to implement and can be deployed in a timely matter to close this session fixation flaw. We can continue working on a future spec that can change the flow some more or add additional security, but for now we should focus on the current security threat. Tackle one issue at a time. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Apr 28, 1:25 pm, Josh Roesslein jroessl...@gmail.com wrote: On Tue, Apr 28, 2009 at 1:12 PM, Brian Eaton bea...@google.com wrote: For apps that can't receive callback URLs, you need a PIN. Yes we will need to manually pass the callback secrete to the application (aka the pin). I think the solution of signed callbacks w/ a callback secrete adequately closes the security hole while not drastically changing the protocol or the user experience. In fact the user won't even be aware of any of these changes unless the application required the transfer of the pin (the callback secrete). Before all they had to do is notify the application. This solution is quick to implement and can be deployed in a timely matter to close this session fixation flaw. We can continue working on a future spec that can change the flow some more or add additional security, but for now we should focus on the current security threat. Tackle one issue at a time. I'd agree on all of this -- it fixes the session fixation flaw and it can be implemented more easily than other solutions. My advocating possible of a PIN or other human-enabled-state mechanism can be worked on as a later spec or an extension to this one if there is sufficient interest. It needn't hold up this process if folks do not want to go that route. --peter --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 1:00 PM, John Kemp j...@jkemp.net wrote: Hi Brian, On Apr 28, 2009, at 1:36 PM, Brian Eaton wrote: On Mon, Apr 27, 2009 at 8:25 PM, pkeane pjke...@gmail.com wrote: I'm happy with OAuth for the typical sorts of social networking, photo-sharing, etc. use cases, and I use it for that. But I'd very much like to be able recommend it for more highly secure scenarios here on campus (I work in higher ed) that might involve confidential records. For OAuth to replace or be used in conjunction with the cuurent campus SSO and federated systems like Shibboleth, we would really need that extra level of verifiable security. Hi Peter - SSO systems such as SAML/OpenID/others all use the equivalent of a callback token to bind the session at the identity provider to the relying party. The fix to the OAuth protocol is to make it look just like the campus SSO and federated systems that you mention above: OpenID: signature on authentication response. SAML POST profile: signature on authentication response. SAML artifact profile: random single-use artifact value. All of those systems pass a value that is unpredictable to the attacker to a trusted location at the consumer site. None of those systems force the user to do anything as obnoxious as manually type a pin at the consumer site. All of these protocols are for Web-browser based SSO, and establish the trust between the consumer and SP (using the OAuth terminology) by relying on Web-browser technologies (ie. an HTTP redirect sent through the user's browser assures that the browser is the same one at SP as it was at consumer). Hi John- On our campus this is indeeed true -- SSO relies on web browser technologies. In cases when we need to authorize third party services (we currently have Blackboard as a consumer for our digital asset management service provider) we have implemented something similar to OAuth. The problems currently under discussion are not an issue, since we DO have consumer authentication (users must sign into Blackboard) and the we use the same AuthN mechanism in both places (our SSO). I do not think the assumptions of OAuth are the same as for those protocols. At least not currently. And I would be wary of going that way without more thought. If you think manually typing a pin increases security, you should explain the attack you're trying to prevent. Why should OAuth have such a requirement if SAML and OpenID don't? I think the security requirement is that you ensure that the entity making a request to the consumer to start the OAuth process is the same entity which is authenticated to the SP. Are you arguing that the callback URL suffices in that regard? I agree that ensuring that u...@consumer (either at the start OR when requesting access token) == u...@sp is the key. The main reasons I have for pushing this are: 1. it guards against scenarios we do not yet envision (like whitelisting good guys rather than trying to blacklist bad guys) 2. it offers the chance to keep the protocol very simple (perhaps even make some things simpler), although at the expense of a slightly more cumbersome user experience. --peter Cheers, - johnk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: How should I distinguish between approved or denied authorization?
On 28/04/2009, at 9:45 PM, J. Adam Moore wrote: How does one typically indicate, in the authorization callback, whether the Request Token was approved or denied? I think you send a 401 error... Er, sorry, perhaps my question was unclear. Authorization of a request token is an exchange between User and Service Provider. After a rejected authorization, I want to notify the Consumer that it was rejected, and the spec suggests that it MAY be done by invoking the callback. What I want to know is, how should I let the Consumer know the token was rejected vs approved? -- cheers, Mike Williams --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
I can't help but think that if our libraries were good enough, people wouldn't run into these problems in the first place. Maybe I'm too optimistic, but I would hope that most people using OAuth never have to implement the parameter encoding themselves. There were really specific reasons we did the parameter encoding the way we did... On Tue, Apr 28, 2009 at 12:15 PM, John Panzer jpan...@acm.org wrote: IIRC, I believe the signing is a workaround for environments that can't or don't want to support SSL. And SSL is problematic primarily for small SPs that can't justify purchase of their own certs. Unfortunately, this puts a burden on clients. Also, most of these come down to encoding issues, which are just always tricky IMHO. Either you end up breaking immediately (because your signature doesn't match) or breaking in edge/subtle cases (because your data mostly matches, except when some idiot sticks an ampersand in the middle of that one string...). Not sure which is worse in the long term, though obviously the break-immediately-with-no-feedback paradigm feels much more frustrating. Perhaps any interop tester service should have a 'forgiving' mode that just logs signature validation failures (but lets the code proceed), but also displays very explicitly what it thought the signature base string was and what it calculated. feedvalidator.org does something similar for RSS and Atom feeds, and it's a fantastic resource for experimenting and fixing things. OAuth is more complicated than feeds but it didn't have even that level of testing support. -John On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist h...@granqvist.comwrote: OAuth is complex. Witness last weeks crazy rush to fix something that was visible in the protocol all along. But no one saw it ... most likely because of protocol complexity. Seeing as Kent's confessions are mostly around signature: it's odd that an authorization protocol needs to specify signature mechanisms ... at all. The end result of an OAuth protocol flow is: * some state on the provider, and * some manifestation of this state on the consumer, who uses this to authenticate the provider when accessing the resource. An authz protocol should encompass how to clearly describe resources, operations, and parties authorized. To do that you really need no other info than URLs and operations. There is no need to bounce this information via the consumer: * The consumer performs an operation on a resource, and * The provider checks to see whether the consumer is allowed. The manner in which the provider authenticates the consumer should be completely independent from the authorization protocol. Forcing any style of authentication is a bit draconian. (A token is tied to a secret for authentication) There are also other issues with baking this all into one protocol. For example, only the provider has to be the one issuing and consuming tokens. This format is opaque. This means I cannot issue my own authorizations -- ahead of time if I wants -- nor can I move them around providers... For some reason OAuth came out as a bit of a REST anti-pattern. Access to resources now are shrouded inside an odd mix of additional protocol flows and signature mechanisms. With non-easily addressable consumers (like desktop apps) you run into the turtles all the way down problem when introducing authentication inside an authorization protocol: you can issue secrets and tokens to an app, or try one of the n-legged approaches, but they fail as you never can be sure who or what you're ultimately authenticating. I'm probably rambling a bit, just some thoughts, Hans On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina chris.mess...@gmail.com wrote: Is OAuth this hard for everyone else? http://kentbrewster.com/oauth-confessions/ *Sniff*. Chris -- Chris Messina Open Web Advocate factoryjoe.com // diso-project.org // openid.net // vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: How should I distinguish between approved or denied authorization?
Upon receiving the callback, the Consumer should try to get an Access Token. You should return a 401 to indicate that authorization was denied. On Tue, Apr 28, 2009 at 1:30 PM, Mike Williams m...@dogbiscuit.org wrote: On 28/04/2009, at 9:45 PM, J. Adam Moore wrote: How does one typically indicate, in the authorization callback, whether the Request Token was approved or denied? I think you send a 401 error... Er, sorry, perhaps my question was unclear. Authorization of a request token is an exchange between User and Service Provider. After a rejected authorization, I want to notify the Consumer that it was rejected, and the spec suggests that it MAY be done by invoking the callback. What I want to know is, how should I let the Consumer know the token was rejected vs approved? -- cheers, Mike Williams --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 8:46 AM, Blaine Cook rom...@gmail.com wrote:
On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane pjke...@gmail.com wrote:
Yes, that's right. What it does (for the sake of the SP) is assert
this user on the consumer is indeed the same user that authenticated
at the SP. Authorization always requires authentication (system
needs to know who it is authorizing).
For OAuth, this relationship is simple. The SP authenticates the user,
but authorizes the consumer-plus-request-token pair. The SP *does not*
authorize an authenticated user at the consumer end. That relationship
is up to the consumer to decide.
Put another way, if TweetCash had been given authorization by many
users to access Twitter accounts, they (TweetCash) could impersonate
any one of those accounts in any way they choose. However, it's a
trust relationship. If TweetCash were to abuse that trust, then
Twitter has the ability to disable their access wholesale (via the
consumer key) or the users have the ability to revoke access on a
case-by-case bases. At no point can Twitter *guarantee* that TweetCash
isn't abusing the trust, but it's probably impossible to do so without
creating an unusable technology, particularly for the sorts of
problems we're trying to solve.
Sorry -- I did not completely get what you were saying at first. Yes,
the SP definitely places a lot of trust in the consumer to do the
right thing regarding the authorizations it has granted that
consumer, and the ability to disable that access wholesale is a great
feature of OAuth. I certainly did not mean to suggest that the SP
should be able to guarantee that the consumer is not abusing that
trust (indeed the SP-consumer trust is a core basis upon which OAuth
is based). My goal is to make sure we have a spec that, given a
good consumer and a good SP, will not allow a bad user to
victimize a good user.
--peter
The exploit that we're dealing with is that the consumer has no way to
ensure that the SP has authorized access to the intended party. The
verification token *does* ensure this, since it guarantees that the
person that clicks Authorize {consumer} is the same one that is
interacting with the consumer, and that's all we're trying to solve.
OAuth does not, and should not, attempt to authenticate identity
across sites.
b.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
OAuth group.
To post to this group, send email to oauth@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: CANCELLED: San Francisco meetup this Tuesday 5pm
Actually, I was going to go too, but I didn't RSVP. Allen Gilles Devaux wrote: Do you plan to postpone it? I did not realize I had to respond and was going to show up. --Gilles On Mon, Apr 27, 2009 at 11:32 PM, Chris Messina chris.mess...@gmail.com wrote: :( Seems like 5 people would be a good-sized group to actually get some real work done. Of course it's up to you and then folks who had signed up to attend, but I wouldn't be discouraged by what might appear to be a relatively small sized number of attendees. Chris On Mon, Apr 27, 2009 at 2:04 PM, Leah Culver leah.cul...@gmail.com wrote: Since less than 5 people have responded, I'm cancelling this meeting. Sorry about the short notice, Leah On Fri, Apr 24, 2009 at 2:42 PM, Leah Culver leah.cul...@gmail.com wrote: Hi all, My eyes hurt from trying to read long email threads. There's quite a few good ideas for helping protect against the current security issue and it will be helpful to get together to discuss. Here's the details: OAuth Meetup Tuesday, Apr 28th at 5pm Six Apart 548 4th Street I'll try to get the conference call stuff working too - more about this later. Sorry for the short notice! I'll try to summarize the meeting and get the notes back in the mailing list or wiki. Leah -- Chris Messina Open Web Advocate factoryjoe.com // diso-project.org // openid.net // vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
Agreed. Granted, I'm starting to think that there ought to be a specification for how the libraries are put together, but that's probably beside the point. I will note that from the library point of view, you really want to minimize the amount of thought that your end user has to give in order to use your stuff. Case in point: .Net has the nasty habit of returning lower case hex values in the encoded results. If your library doesn't return a fully formed result (and instead just returns a calculated signature string), you're rolling out the red carpet of frustration for whoever picks up your library and tries to use it since they now have to replicate how the SBS was generated to give your signature. There are definite, valid reasons for why OAuth is built the way it is. It's also really easy for folks here to get lost in the details of OAuth and forget that it's just a tiny part of a much larger set of issues for whatever developer wants to use it to solve a problem. For folks out there building apps and services: Easy trumps detailed. Jonathan Sergent wrote: I can't help but think that if our libraries were good enough, people wouldn't run into these problems in the first place. Maybe I'm too optimistic, but I would hope that most people using OAuth never have to implement the parameter encoding themselves. There were really specific reasons we did the parameter encoding the way we did... On Tue, Apr 28, 2009 at 12:15 PM, John Panzer jpan...@acm.org mailto:jpan...@acm.org wrote: IIRC, I believe the signing is a workaround for environments that can't or don't want to support SSL. And SSL is problematic primarily for small SPs that can't justify purchase of their own certs. Unfortunately, this puts a burden on clients. Also, most of these come down to encoding issues, which are just always tricky IMHO. Either you end up breaking immediately (because your signature doesn't match) or breaking in edge/subtle cases (because your data mostly matches, except when some idiot sticks an ampersand in the middle of that one string...). Not sure which is worse in the long term, though obviously the break-immediately-with-no-feedback paradigm feels much more frustrating. Perhaps any interop tester service should have a 'forgiving' mode that just logs signature validation failures (but lets the code proceed), but also displays very explicitly what it thought the signature base string was and what it calculated. feedvalidator.org http://feedvalidator.org does something similar for RSS and Atom feeds, and it's a fantastic resource for experimenting and fixing things. OAuth is more complicated than feeds but it didn't have even that level of testing support. -John On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist h...@granqvist.com mailto:h...@granqvist.com wrote: OAuth is complex. Witness last weeks crazy rush to fix something that was visible in the protocol all along. But no one saw it ... most likely because of protocol complexity. Seeing as Kent's confessions are mostly around signature: it's odd that an authorization protocol needs to specify signature mechanisms ... at all. The end result of an OAuth protocol flow is: * some state on the provider, and * some manifestation of this state on the consumer, who uses this to authenticate the provider when accessing the resource. An authz protocol should encompass how to clearly describe resources, operations, and parties authorized. To do that you really need no other info than URLs and operations. There is no need to bounce this information via the consumer: * The consumer performs an operation on a resource, and * The provider checks to see whether the consumer is allowed. The manner in which the provider authenticates the consumer should be completely independent from the authorization protocol. Forcing any style of authentication is a bit draconian. (A token is tied to a secret for authentication) There are also other issues with baking this all into one protocol. For example, only the provider has to be the one issuing and consuming tokens. This format is opaque. This means I cannot issue my own authorizations -- ahead of time if I wants -- nor can I move them around providers... For some reason OAuth came out as a bit of a REST anti-pattern. Access to resources now are shrouded inside an odd mix of additional protocol flows and signature mechanisms. With non-easily addressable consumers (like desktop
[oauth] Amusing Flickr Support Message
http://www.flickr.com/help/forum/en-us/96092/ User messaging ftw! Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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] One-time only token exchange?
Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: One-time only token exchange?
I agree with you Leah that it should be outlined in the spec that the SP should limit the number of access token requests to prevent brute force attacks. This would really make session fixation impossible w/o a callback. On Tue, Apr 28, 2009 at 5:02 PM, Leah Culver leah.cul...@gmail.com wrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: One-time only token exchange?
Actually, I think it's a pretty small change to the spec. In section 6.3.2 Service Provider Grants an Access Token ( http://oauth.net/core/1.0/#auth_step3), it says: The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes)http://oauth.net/core/1.0/#http_codes . Perhaps an updated version could say something like (changes in red): The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - There have been no prior attempts to exchange this Request Token for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD invalidate or delete the request token and respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes) http://oauth.net/core/1.0/#http_codes. On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver leah.cul...@gmail.com wrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: One-time only token exchange?
Sometimes users may hit the 'reload' button in the consumer page and that may result in the request token swap being sent twice. So, this implies a requirement on consumers to immediately redirect users to a different page so that the back and reload buttons won't re-submit the request. In practice, with the new changes, it would be hard for an attacker to get hold of the user's response within a short time frame. Since the request tokens are single time use already, I believe there is no reason for additional spec changes, though probably a discussion on a security considerations section of the spec (which should be moved from appendix to main document) may well be indicated. On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver leah.cul...@gmail.com wrote: Actually, I think it's a pretty small change to the spec. In section 6.3.2 Service Provider Grants an Access Token ( http://oauth.net/core/1.0/#auth_step3), it says: The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes)http://oauth.net/core/1.0/#http_codes . Perhaps an updated version could say something like (changes in red): The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - There have been no prior attempts to exchange this Request Token for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD invalidate or delete the request token and respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes) http://oauth.net/core/1.0/#http_codes. On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver leah.cul...@gmail.comwrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: One-time only token exchange?
The SP could optionally add a buffer to account for mistypes. Maybe allow 2, 3, 4, etc attempts. To the consumer it doesn't really matter how many attempts are allowed, they can just keep trying until they are notified the request token is no longer valid. The spec should outline how the client will be notified when a token becomes invalid (status code, parameter?). On Tue, Apr 28, 2009 at 5:21 PM, Breno de Medeiros br...@google.com wrote: Sometimes users may hit the 'reload' button in the consumer page and that may result in the request token swap being sent twice. So, this implies a requirement on consumers to immediately redirect users to a different page so that the back and reload buttons won't re-submit the request. In practice, with the new changes, it would be hard for an attacker to get hold of the user's response within a short time frame. Since the request tokens are single time use already, I believe there is no reason for additional spec changes, though probably a discussion on a security considerations section of the spec (which should be moved from appendix to main document) may well be indicated. On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver leah.cul...@gmail.comwrote: Actually, I think it's a pretty small change to the spec. In section 6.3.2 Service Provider Grants an Access Token ( http://oauth.net/core/1.0/#auth_step3), it says: The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes)http://oauth.net/core/1.0/#http_codes . Perhaps an updated version could say something like (changes in red): The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - There have been no prior attempts to exchange this Request Token for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD invalidate or delete the request token andrespond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes)http://oauth.net/core/1.0/#http_codes . On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver leah.cul...@gmail.comwrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
On Apr 28, 1:37 pm, Jonathan Sergent serg...@google.com wrote: I can't help but think that if our libraries were good enough, people wouldn't run into these problems in the first place. Maybe I'm too optimistic, but I would hope that most people using OAuth never have to implement the parameter encoding themselves. There were really specific reasons we did the parameter encoding the way we did... I'd say a complete stack of test cases with coverage should help folks gain more confidence in sections 5 and 9, which I think seem to be the hardest ones. I like http://oauth.pbworks.com/TestCases but it could be evolved more (I'd look into items that I can add there). Overall I found the beginner's guide and the editor's cut of the spec helping me a lot. Another factor is familiarity with something like OAuth (like experience with writing Flickr/Facebook apps using their non-OAuth API) also helps to hit the ground running, as the core concept is more or less the same albeit non-standard. From my experience I'd say that the spec is hard, OAuth as a concept is not, and if a broader range of test cases would accompany the documentation, that'd make the consumer +provider implementors' lives a lot easier. -cheers, Manish --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: How should I distinguish between approved or denied authorization?
On 29/04/2009, at 6:40 AM, Jesse Myers wrote: Upon receiving the callback, the Consumer should try to get an Access Token. You should return a 401 to indicate that authorization was denied. Yup, cool. So, section 6.2.3 of the spec says: After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token. If the User denies access, the Consumer MAY be notified that the Request Token has been revoked. My reading was that there was some way of representing the revocation (lack of authorization) in the callback. What I'm hearing here, though, is that there isn't ... or at least no standard way. -- cheers, Mike Williams --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: Moving forward
On Tue, Apr 28, 2009 at 11:32 PM, Dossy Shiobara do...@panoptic.com wrote: On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: I also saw 2 additional ideas that might help (and are not necessarily exclusive with the 2 proposals): (3) Make Request tokens one-time only (4) Request that the user logs in at the Consumer before the request token request Requiring the user authenticate to the Consumer doesn't prevent the attack, as the attacker is a legitimate user of Consumer in the attack scenario. What I keep proposing is that the user must authenticate at the _Provider_ before the request token request. This would completely eliminate the attack in the scenario. Right. I think I have seen something like this on this list recently, but the problem is in this wholesale grant model. Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker, S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C. Then, what OAuth does right now is: [1] Get Permission on (Grant access on S:V:data to C:*) by misguiding the user as (Grant access on S:V:data to C) This is not pretty. It is illegal in many countries (not in U.S. though.) And, what you are proposing is to deny the wild card in [1] above and make it explicit, so that it will be like: [2] Get Permission on (Grant access on S:V:data to C:A) which, I think, is a good idea. Under this scenario, in the last vulnerability that we encountered, the victim will be asked to grant permission to C:A, which, he probably would not. =nat And yes, making request tokens one-time only is a MUST, IMHO. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- Nat Sakimura (=nat) http://www.sakimura.org/en/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: One-time only token exchange?
Limiting the lifetime of the Request Token can also reduce the risk. In the attack scenario described an abuser must trick a user to click on the User Authorization URL - this takes some time. The OAuth flow is somewhat 'instant' (I might miss some scenarios on mobile devices or devices without a browser). Of course this does not resolves the underlying problem but might be a good practice. Correct me if I am missing something --Gilles On Tue, Apr 28, 2009 at 3:45 PM, Josh Roesslein jroessl...@gmail.com wrote: The SP could optionally add a buffer to account for mistypes. Maybe allow 2, 3, 4, etc attempts. To the consumer it doesn't really matter how many attempts are allowed, they can just keep trying until they are notified the request token is no longer valid. The spec should outline how the client will be notified when a token becomes invalid (status code, parameter?). On Tue, Apr 28, 2009 at 5:21 PM, Breno de Medeiros br...@google.com wrote: Sometimes users may hit the 'reload' button in the consumer page and that may result in the request token swap being sent twice. So, this implies a requirement on consumers to immediately redirect users to a different page so that the back and reload buttons won't re-submit the request. In practice, with the new changes, it would be hard for an attacker to get hold of the user's response within a short time frame. Since the request tokens are single time use already, I believe there is no reason for additional spec changes, though probably a discussion on a security considerations section of the spec (which should be moved from appendix to main document) may well be indicated. On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver leah.cul...@gmail.com wrote: Actually, I think it's a pretty small change to the spec. In section 6.3.2 Service Provider Grants an Access Token (http://oauth.net/core/1.0/#auth_step3), it says: The Service Provider MUST ensure that: The request signature has been successfully verified. The Request Token has never been exchanged for an Access Token. The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes). Perhaps an updated version could say something like (changes in red): The Service Provider MUST ensure that: The request signature has been successfully verified. The Request Token has never been exchanged for an Access Token. There have been no prior attempts to exchange this Request Token for an Access Token. The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD invalidate or delete the request token and respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes). On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver leah.cul...@gmail.com wrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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: One-time only token exchange?
I agree. The Request Token has never been exchanged for an Access Token. isn't explicitly saying one-time only token, but I believe that is what was intended. Clarifying this line would be sufficient as would requiring the Service Provider log the User out after any request token attempt. This forces the User to login to the Service Provider to start the process of requesting access all over. On Apr 28, 3:13 pm, Leah Culver leah.cul...@gmail.com wrote: Actually, I think it's a pretty small change to the spec. In section 6.3.2 Service Provider Grants an Access Token (http://oauth.net/core/1.0/#auth_step3), it says: The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes)http://oauth.net/core/1.0/#http_codes . Perhaps an updated version could say something like (changes in red): The Service Provider MUST ensure that: - The request signature has been successfully verified. - The Request Token has never been exchanged for an Access Token. - There have been no prior attempts to exchange this Request Token for an Access Token. - The Request Token matches the Consumer Key. ... If the request fails verification or is rejected for other reasons, the Service Provider SHOULD invalidate or delete the request token and respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes) http://oauth.net/core/1.0/#http_codes. On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver leah.cul...@gmail.com wrote: Hmm... I feel like this has been lost in all the hubbub about callbacks. I strongly advocate saying something in the spec about making the token exchange (access token endpoint) one-time use only. By one-time only, I mean that the first time there is an attempt to exchange a request token for an access token, if the request token has not been authorized, then that request token should be marked as invalid. This will make a session fixation attack nearly impossible without a callback. If a service provider allows multiple attempts to exchange the request token a callback is not even necessary for the attack to work! The attacker must only keep trying to exchange the token. I know it's up to the service provider to implement one-time only token exchange, but putting it in the documentation (and libraries) will make it much easier for service providers to do the right thing. Am I missing the discussion about this? Is it on the wiki and I just can't find it? Or is everyone in agreement that this should be added to the docs? Thanks, Leah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@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 -~--~~~~--~~--~--~---
