[oauth] Re: OAuth dissemination at bettersoftware conference in Italy
Great! Thanks for the update Simone! It would be great if we could assemble non-English resources on the wiki! Would you mind adding your slides to this page? https://oauth.pbworks.com/Presentations Thanks! Chris On Thu, May 7, 2009 at 1:06 PM, Simone Tripodi simone.trip...@gmail.comwrote: Hi all OAuth folks!!! Just to notify you that yesterday my colleague Lorenzo Cassulo and I participated in a conference [1] in Florence (Italy), to speak about digital identity and OpenID. In the afternoon, we did a workshop about the OpenStack, focusing the attention on OAuth and PortableContacts, and showing demos related to an hybrid OAuth consumer-provider[2]. We also presented a nice application to combine OpenID with Jabber/XMPP[3]. Being honest, the audience was very good and people enjoyed a lot OAuth protocol and relative applications :) Moreover, it was very nice also meeting Luca Mearelli (he participates in this mailing list too) who helped us in replying questions about OAuth, so have to say a big thanks to him :) Slides will be available online soon on the conference website and/or slideshare, for who is interested I'll send the links; unfortunately, they are written in Italian language, since the audience was totally Italian :P You can also read what happened following my twitter page on [4]. Best regards Simone Tripodi [1] http://www.bettersoftware.it/ [2] http://oauth.asemantics.com/hybrid/ [3] http://myid.asemantics.com/ [4] http://twitter.com/simonetripodi -- http://www.google.com/profiles/simone.tripodi -- 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] Friend Connect Vs OAuth
Hello friends i am confused with GFC and OAuth. In the former we can directly integrate the Login module but not the same in the later. Can any one please suggest me which to go. I am good in Java / JEE. Thanks in Advance Ganesh INDIA --~--~-~--~~~---~--~~ 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: Friend Connect Vs OAuth
On May 7, 9:58 am, Ganex gan...@gmail.com wrote: Hello friends i am confused with GFC and OAuth. In the former we can directly integrate the Login module but not the same in the later. Can any one please suggest me which to go. I am good in Java / JEE. Thanks in Advance Ganesh INDIA Per my understanding, GFC implements a cookie based auth scheme, while OAuth is a much more involved spec, including the pre-auth steps as well as including more than just a cookie to access protected resources. It is not so much about programming languages, but depends on your application and its interaction with OpenSocial and/or any other platform like NetFlix/Twitter. Chris has a blog post here : http://blog.oauth.net/2007/11/07/oauth-and-opensocial/ What application are you trying to design? -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: OAuth Core 1.0 Rev A, Draft 2
2009/5/8 Dirk Balfanz dirk.balf...@gmail.com You didn't like my the verification code matches the request token language? Dirk. IMHO that implies that the verification code value has some intrinsic link to the request token value, which is presumptuous about the implementation method. All we want to say is that the verification code matches the expected verification code at the SP. Without implying how the SP saves or comes about the expected verification code. O --~--~-~--~~~---~--~~ 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: Twitter Broke OAuth's Account?
Yeah, they've taken that account over and given it back a few times on and off. I don't know that we'd use it much, and I prefer Twitter to be support OAuth anyway, so I'll consider it 'contributed' to the cause. :) Chris On Wed, May 6, 2009 at 4:59 PM, Tane Piper t...@digitalspaghetti.me.ukwrote: Just checked in Tweetdeck and @Oauth still works, it's just the URL that is b0rked. Tane Piper http://digitalspaghetti.me.uk - Blog http://learningandroid.org - Learning Android email/gtalk: t...@digitalspaghetti.me.uk mobile: +447815 101802 twitter: http://twitter.com/tanepiper This email is: [ ] blogable [ x ] ask first [ ] private Sent from Edinburgh, City of Edinburgh, United Kingdom On Wed, May 6, 2009 at 3:56 PM, Tane Piper t...@digitalspaghetti.me.uk wrote: Hey, Just in passing I was on the site and I wanted to make sure I was following the OAuth twitter when I saw the link on the Google Code site. But it looks like Twitter, rather than check that OAuth had an account, have taken the URL for themselves for their own service. Now going to http://twitter.com/oauth takes you to an Applications Using Twitter page instead of the twitter stream! Might want to take that up with them. -- 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: OAuth Core 1.0 Rev A, Draft 2
On Thu, May 7, 2009 at 12:45 PM, Owen Evans owenmcev...@gmail.com wrote: 2009/5/8 Dirk Balfanz dirk.balf...@gmail.com You didn't like my the verification code matches the request token language? Dirk. IMHO that implies that the verification code value has some intrinsic link to the request token value, which is presumptuous about the implementation method. I think that any implementation that doesn't have such an intrinsic link (be it as an explicit link in a database, as a signature, or perhaps as an implicit link through some other means) is broken, hence my proposed language. It might be the case that the verification code matches the user that approved the request token is good enough - it seems to prevent the session fixation attack we identified. But I thought that for good measure, we should actually require the verification code to be bound to a particular request token, not just a particular user (I don't know what can happen if we allow a user to approve two different request tokens, and then swap the verifiers he got for the two before returning to the Consumer). All we want to say is that the verification code matches the expected verification code at the SP. Without implying how the SP saves or comes about the expected verification code. That, again, assumes that there are two verification codes - the expected one, and the actual one. If the way I'm implementing this is have my verification code be the DSA signature of the request token, then there is no way for me to calculate the expected verification code (re-doing the signature on the request token will yield a different signature). All I can do is check that the actual one is kosher (b/c it matches the request token, not some expected verification code). Dirk. O --~--~-~--~~~---~--~~ 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: OAuth Core 1.0 Rev A, Draft 2
I realise there's a link between the Token and the Verification code but not the Verification Code and Token VALUE which is how I would read the first one, i.e. the verification value has to be some kind of hash of the oauth_token value. Anyway, I'm playing devils advocate and it's not like I mind anyway the language all looks fine, it's just I'm explaining how I read it (and therefor some other laymen would/could read it). *The verification code is the same as the verification code sent by the stored procedure during the previous step?* O 2009/5/8 Dirk Balfanz dirk.balf...@gmail.com On Thu, May 7, 2009 at 12:45 PM, Owen Evans owenmcev...@gmail.com wrote: 2009/5/8 Dirk Balfanz dirk.balf...@gmail.com You didn't like my the verification code matches the request token language? Dirk. IMHO that implies that the verification code value has some intrinsic link to the request token value, which is presumptuous about the implementation method. I think that any implementation that doesn't have such an intrinsic link (be it as an explicit link in a database, as a signature, or perhaps as an implicit link through some other means) is broken, hence my proposed language. It might be the case that the verification code matches the user that approved the request token is good enough - it seems to prevent the session fixation attack we identified. But I thought that for good measure, we should actually require the verification code to be bound to a particular request token, not just a particular user (I don't know what can happen if we allow a user to approve two different request tokens, and then swap the verifiers he got for the two before returning to the Consumer). All we want to say is that the verification code matches the expected verification code at the SP. Without implying how the SP saves or comes about the expected verification code. That, again, assumes that there are two verification codes - the expected one, and the actual one. If the way I'm implementing this is have my verification code be the DSA signature of the request token, then there is no way for me to calculate the expected verification code (re-doing the signature on the request token will yield a different signature). All I can do is check that the actual one is kosher (b/c it matches the request token, not some expected verification code). Dirk. O --~--~-~--~~~---~--~~ 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: Confirm callback when getting access token
I do not think there is anything fundamentally wrong with James proposal. However, I have not given it near the same level of scrutiny that I did to the existing proposal. Plenty of eyes were intensely focused on it during the week immediately after the advisory came out. The net result is that the existing proposal was widely discussed and has received 1000's of hours of total attention from developers and security experts by now, from an implementation issues perspective sure, but also critically from a security perspective. On Wed, May 6, 2009 at 10:56 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: James, thanks for adding the proposal and offering deeper insight into its details. I would like to ask you to add it to the wiki page so we have it documented. I would like to ask people if they have strong views for or against this proposal. So far a few people raised concerns which James tried to addressed, but I have not heard from anyone who would like to advocate this as the proposal patch. I think any proposal deserves to be considered, but we need more people to advocate it for it to remain on the table. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Manger, James H Sent: Wednesday, May 06, 2009 7:31 PM To: oauth@googlegroups.com Subject: [oauth] Re: Confirm callback when getting access token Brian, There are two attacks: attacker gets victim's access; and login CSRF. They are distinct attacks, causing different damage, and with different defences -- but they are both sort of related to session fixation. Consequently, I find the term session fixation a bit ambiguous in these discussions. The first attack is the OAuth-specific issue that attention is focused on. Callback-with-request-token and callback-with-access-token both address the first attack. Neither addresses login CSRF. A Referer check at the callback URI is one way to combat login CSRF against the callback URI. I wasn't suggesting that this defeats the first attack as well. I have earlier suggested a Referer check *at the authorization URI* could combat the first attack. I still think that could be quite an effective temporary fix, though Allen Tom suggested issues with social networking sites that I haven't fully groked. I don't think encoding all state in the callback URI implies a vulnerability to session fixation. There is usually no session yet. Encoding all state in the callback URI might make it more important to explicitly address login CSRF, but they are still separate issues. Options for client-side state with 1.0 include (at least): * callback URI * cookies * javascript variables I don't want to remove any option if we don't have to. JavaScript variables presumably fail on clients that disable JavaScript. Cookies might be blocked by some clients, don't work across domains, and have their own issues. Breno suggested that by removing the callback URI as an option for storing state (by adopting callback-with-request-token), developers are more likely to choose a state management approach that accidentally prevents login CSRF. I really like the idea of making the easiest option for developers the secure choice. However, I feel that while callback-with-request-token might make the easiest *remaining* option a secure choice, it only does so by eliminating other options that can be easier and still be secure. [What is easiest varies with circumstance, of course] James Manger james.h.man...@team.telstra.com Identity and security team — Chief Technology Office — Telstra -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Thursday, 7 May 2009 3:44 AM To: oauth@googlegroups.com Subject: [oauth] Re: Confirm callback when getting access token On Tue, May 5, 2009 at 9:34 PM, Manger, James H james.h.man...@team.telstra.com wrote: I would prefer to fix OAuth security issue 2009-1 without unnecessarily preventing state-management options that previously worked, and without requiring cookies where they were not previously necessary. I'm pretty sure that any client that encodes all state in the callback URL is still vulnerable to session fixation. You mentioned using referer or origin HTTP headers to prevent XSRF of the callback URL, but those don't actually work to prevent the session fixation attack. (Referer and Origin will always point to the SP.) (Nit: the protocol doesn't actually require cookies. Other types of client-side state (javascript variables for web browsers, disk or memory storage for installed apps) are perfectly viable.) -- --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
[oauth] Re: Confirm callback when getting access token
The risk to the future of OAuth from callback-with-request-token's structural change is greater than the risk from shorter security review of callback-with-access-token. -- To my mind, the OAuth delegation flow really starts when a service says, in response to an HTTP request: This request is rejected, but it can succeed if a user delegates you their permission to make this request. You can get that permission using the OAuth protocol, for which you will need a request token, request secret, and an authorization URI. Today, a consumer app uses hard-wired service-specific knowledge to make an explicit request for a Request Token. It knows it is doing OAuth before it makes the first request. In future, I hope consumer apps can interoperate with services more dynamically. An app will not always know that OAuth is required when it makes the first request so it cannot include an OAuth callback URI in the first request. That will require a second request. I think it is quite likely that the callback-with-request-token proposal will require an extra round-trip (compared other solutions such as the callback-with-access-token proposal) once discovery options are defined. Callback-with-request-token changes the *structure* of the OAuth delegation flow by making the consumer (instead of the service) send the first message that is specific to OAuth delegation. This structural change is somewhat hidden with OAuth Core 1.0, because 1.0 tightly couples request signing and delegation. It will become more obvious as those independent aspects are separated, which is starting with Eran's IETF OAuth draft. We obviously don't want to define discovery now before fixing the security issue, so we should be very wary about making structural changes now since we are not taking the time to understand their implications. The risk to the future of OAuth from callback-with-request-token's structural change is greater than the risk from shorter security review of callback-with-access-token. James Manger james.h.man...@team.telstra.com Identity and security team — Chief Technology Office — Telstra --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
