[oauth] Re: Is 4-legged OAuth possible?
I'm not sure a solution that requires, in this example, TwitPic to be a OAuth provider is good. The OAuth access to Twitter should probably remain independent for both TwitPic and TweetDeck. To post a picture, TwitPic would only need to verify the TweetDeck request, and posting to Twitter would require independent OAuth access tokens. If there were an automated way for TweetDeck to use the OAuth Provider (Twitter) to verify the user to TwitPic, there wouldn't need to be a step that involves going through the OAuth process for TwitPic. The dance sounds reasonable for this example, but keep in mind people use lots of clients and there are many 3rd party twitter apps. The user experience is far worse than giving a username / password pair. Ivan http://tipjoy.com On Mar 25, 1:42 pm, Martin Atkins wrote: > Ethan Jewett wrote: > > 1. The user authorized TwitPic to access Twitter (OAuth dance #1). > > 2. The user authorizes TweetDeck to use the TwitPic API (OAuth dance #2). > > It seems like this could actually be made to look like a single "dance": > > * User of TweetDeck requests a connection to TwitPic. > * TwitPic asks the user to log in. > * TwitPic checks if it already has a Twitter OAuth access token for this > user. If it does, it skips the next step. > * TwitPic initiates an OAuth dance with Twitter to get a Twitter access > token. > * TwitPic issues an OAuth access token connected to the TwitPic account, > which is indirectly connected to the Twitter account. > > So the user sees TweetDeck -> TwitPic -> Twitter -> TweetDeck in the > initial bootstrap case. This is likely to make the user a little > confused, but perhaps the TwitPic UI can say something like "Before > can use TwitPic, we must connect to your Twitter > account." --~--~-~--~~~---~--~~ 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: load testing an oAuth provider?
On Thu, Mar 26, 2009 at 3:26 AM, Seth Fitzsimmons wrote: > >>> * pre-generating a list of signed URLs and running them through httperf >> >> Could you explain this a bit more? How did you pre-generate URLs? >> Were you just testing use of the access token, or the full dance to obtain >> it? > > I do the dance ahead of time to obtain however many access tokens that > I want to use to load test. Once I have those, I plug them into the > URL generator which creates signed URLs and outputs them to stdout > (rather than executing those queries). At that point, I have a file > containing n signed URLs that I can plug into httperf, loadrunner, > etc. Ah ok - we are trying to load test the oauth dance itself too thanks for your thoughts --~--~-~--~~~---~--~~ 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] why not have server generate nonce values
I've been reading up on the oauth specs and when came to the section about nonce and timestamps I wondered "why not have the server send the nonce?". Benefits of this: + Server only needs to track the last nonce it sent to validate the next request + Don't need to store every nonce ever used When the server responds back from the previous request it can include the next nonce value in the header. So when we construct our next signature we have our next nonce. Attackers still can't construct a valid signature even if they see the next nonce. So why have the client generate the nonce on the fly? I'm no security professional, so I might be overlooking a flaw with the above method. --~--~-~--~~~---~--~~ 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: Security through obscurity?
Both of you are right. Technically there's no irrefutable way to prevent leaking tokens in desktop apps, so forcing pre-registration is simply a way to get developers to agree not to casually release what qualifies as "confidential information". If you do leak said information (i.e. By embedding it in your desktop app) you agree to hold harmless the SP that provided you the token if/when they shut off your key. The two solutions are complements. Whether the legal solution fully recognizes the limitations of technical solution is another story. Chris On 3/25/09, Eran Hammer-Lahav wrote: > > That's simply not true. When you manually register an application you agree > to legal terms with how you may or may not use the user's data you are > accessing and other legal requirements. Without this agreement, users could > sue the service provider for bad acts by the application. > > EHL > >> -Original Message- >> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf >> Of Martin Atkins >> Sent: Wednesday, March 25, 2009 12:28 PM >> To: oauth@googlegroups.com >> Subject: [oauth] Re: Security through obscurity? >> >> >> Eran Hammer-Lahav wrote: >> > But it does make the lawyers happy. >> > >> >> Maybe the lawyers ought to listen to the technical folks telling them >> that requiring pre-registration of desktop apps achieves nothing >> whatsoever. >> >> It can't be healthy to have lawyers who believe they have an effective >> mechanism that is in fact completely ineffective. >> >> >> >> > > > > -- Chris Messina Citizen-Participant & Open Web Advocate factoryjoe.com // diso-project.org // 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: Using OAuth as a Login Strategy
I'm doing this with the Twitter API, and what I'm doing is requesting the Access Token, then verifying its credentials, using the API. A little bit backwards, I realize, but it works. On Mar 18, 11:42 pm, jmkrist...@gmail.com wrote: > Google has been working to combine OpenID and > OAuth:http://googledataapis.blogspot.com/2009/01/bringing-openid-and-oauth-...http://sites.google.com/site/oauthgoog/Home --~--~-~--~~~---~--~~ 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: Security through obscurity?
That's simply not true. When you manually register an application you agree to legal terms with how you may or may not use the user's data you are accessing and other legal requirements. Without this agreement, users could sue the service provider for bad acts by the application. EHL > -Original Message- > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > Of Martin Atkins > Sent: Wednesday, March 25, 2009 12:28 PM > To: oauth@googlegroups.com > Subject: [oauth] Re: Security through obscurity? > > > Eran Hammer-Lahav wrote: > > But it does make the lawyers happy. > > > > Maybe the lawyers ought to listen to the technical folks telling them > that requiring pre-registration of desktop apps achieves nothing > whatsoever. > > It can't be healthy to have lawyers who believe they have an effective > mechanism that is in fact completely ineffective. > > > > --~--~-~--~~~---~--~~ 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: Security through obscurity?
Eran Hammer-Lahav wrote: > But it does make the lawyers happy. > Maybe the lawyers ought to listen to the technical folks telling them that requiring pre-registration of desktop apps achieves nothing whatsoever. It can't be healthy to have lawyers who believe they have an effective mechanism that is in fact completely ineffective. --~--~-~--~~~---~--~~ 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: Security through obscurity?
But it does make the lawyers happy. EHL > -Original Message- > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > Of Martin Atkins > Sent: Wednesday, March 25, 2009 10:35 AM > To: oauth@googlegroups.com > Subject: [oauth] Re: Security through obscurity? > > > Allen Tom wrote: > > > > We believe that it is impossible to safeguard any secrets embedded in > > downloadable client applications. Someone with a debugger and some > > patience will be able to extract the secrets very quickly. Likewise, > any > > secret protocol between a downloadable client and a server can also > be > > easily reverse engineered. Therefore, it's impossible to securely > > identify a client application, and a downloadable client > application's > > consumer key (even when signed with its consumer secret) is about as > > meaningful as your browser's HTTP User-Agent string. > > > > With that in mind, it seems like requiring preregistration of desktop > clients is providing no value whatsoever and is just an unnecessary > barrier to creating an app. > > It would be interesting to figure out how a User-Agent-like mechanism > can be added to OAuth so that clients can say who they are in a > browser-like way without having to pre-register. > > I would expect SPs to treat such unregistered callers the way they > treat > registered desktop clients today. This may include, for example, not > allowing the app to renew its access token without going through the > interactive user approval flow a second time. > > This unregistered mode would also be useful for OpenID-style web-based > interactions where there's no pre-existing business relationship, as > long as the web app is willing to accept the limitations of being an > unregistered consumer. The app may wish to register for certain big > providers to get added value in the common cases, but can do ad-hoc > authorization against lesser-known or self-hosted SPs. > > > --~--~-~--~~~---~--~~ 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: Security through obscurity?
Allen Tom wrote: > > We believe that it is impossible to safeguard any secrets embedded in > downloadable client applications. Someone with a debugger and some > patience will be able to extract the secrets very quickly. Likewise, any > secret protocol between a downloadable client and a server can also be > easily reverse engineered. Therefore, it's impossible to securely > identify a client application, and a downloadable client application's > consumer key (even when signed with its consumer secret) is about as > meaningful as your browser's HTTP User-Agent string. > With that in mind, it seems like requiring preregistration of desktop clients is providing no value whatsoever and is just an unnecessary barrier to creating an app. It would be interesting to figure out how a User-Agent-like mechanism can be added to OAuth so that clients can say who they are in a browser-like way without having to pre-register. I would expect SPs to treat such unregistered callers the way they treat registered desktop clients today. This may include, for example, not allowing the app to renew its access token without going through the interactive user approval flow a second time. This unregistered mode would also be useful for OpenID-style web-based interactions where there's no pre-existing business relationship, as long as the web app is willing to accept the limitations of being an unregistered consumer. The app may wish to register for certain big providers to get added value in the common cases, but can do ad-hoc authorization against lesser-known or self-hosted SPs. --~--~-~--~~~---~--~~ 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: Is 4-legged OAuth possible?
Ethan Jewett wrote: > 1. The user authorized TwitPic to access Twitter (OAuth dance #1). > 2. The user authorizes TweetDeck to use the TwitPic API (OAuth dance #2). It seems like this could actually be made to look like a single "dance": * User of TweetDeck requests a connection to TwitPic. * TwitPic asks the user to log in. * TwitPic checks if it already has a Twitter OAuth access token for this user. If it does, it skips the next step. * TwitPic initiates an OAuth dance with Twitter to get a Twitter access token. * TwitPic issues an OAuth access token connected to the TwitPic account, which is indirectly connected to the Twitter account. So the user sees TweetDeck -> TwitPic -> Twitter -> TweetDeck in the initial bootstrap case. This is likely to make the user a little confused, but perhaps the TwitPic UI can say something like "Before can use TwitPic, we must connect to your Twitter account." --~--~-~--~~~---~--~~ 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: Is 4-legged OAuth possible?
This would be two three-legged OAuth scenarios, correct? 1. The user authorized TwitPic to access Twitter (OAuth dance #1). 2. The user authorizes TweetDeck to use the TwitPic API (OAuth dance #2). 3a. The user does something in the consumer (Tweetdeck) that invokes a provider (TwitPic) API method using the TwitPic/Tweetdeck token 3b. This requires a call to Twitter, at which point the new consumer (TwitPic) invokes a provider (Twitter) API method using the Twitter/TwitPic token. 3c. Once the TwitPic/Twitter roundtrip is complete, TwitPic passes back a result to TweetDeck, completing the original API call. Whew, that was a mouthful. Of course, this requires that TwitPic be an OAuth provider and consumer and currently it looks like it may be neither, so this may not be the best example. Is that correct? Are there any examples of this, or better ways to do this? Ethan On Wed, Mar 25, 2009 at 11:13 AM, Ivan Kirigin wrote: > > Hi, > > I recently integrated Twitter's OAuth into my site, http://tipjoy.com > > It's a great user experience and a lot like Facebook Connect. > > But I ran into a problem when developing our API for Twitter > applications to use Tipjoy for payments. OAuth tokens aren't > transferable like a username & password. For example, a Twitter user > on TweetDeck can input a username & password, which lets TweetDeck > post a picture to TwitPic. If TweetDeck were granted OAuth access to > the user's Twitter account, TwitPic couldn't verify the access tokens > easily, and couldn't communicate to Twitter with them. > > How can we power this 4-legged OAuth? Twitter could act as an > intermediary, to tell TwitPic that the request from TweetDeck is > authorized. > > I'm told Facebook is coming up with a solution for Facebook Connect. > As the environment for social apps becomes more connected, this > communication between 3rd parties about users on the OAuth provider > become more important. > > What do you all think? > > Thanks, > Ivan > http://tipjoy.com > > > > --~--~-~--~~~---~--~~ 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] Is 4-legged OAuth possible?
Hi, I recently integrated Twitter's OAuth into my site, http://tipjoy.com It's a great user experience and a lot like Facebook Connect. But I ran into a problem when developing our API for Twitter applications to use Tipjoy for payments. OAuth tokens aren't transferable like a username & password. For example, a Twitter user on TweetDeck can input a username & password, which lets TweetDeck post a picture to TwitPic. If TweetDeck were granted OAuth access to the user's Twitter account, TwitPic couldn't verify the access tokens easily, and couldn't communicate to Twitter with them. How can we power this 4-legged OAuth? Twitter could act as an intermediary, to tell TwitPic that the request from TweetDeck is authorized. I'm told Facebook is coming up with a solution for Facebook Connect. As the environment for social apps becomes more connected, this communication between 3rd parties about users on the OAuth provider become more important. What do you all think? Thanks, Ivan http://tipjoy.com --~--~-~--~~~---~--~~ 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: load testing an oAuth provider?
>> * pre-generating a list of signed URLs and running them through httperf > > Could you explain this a bit more? How did you pre-generate URLs? > Were you just testing use of the access token, or the full dance to obtain it? I do the dance ahead of time to obtain however many access tokens that I want to use to load test. Once I have those, I plug them into the URL generator which creates signed URLs and outputs them to stdout (rather than executing those queries). At that point, I have a file containing n signed URLs that I can plug into httperf, loadrunner, etc. seth --~--~-~--~~~---~--~~ 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: load testing an oAuth provider?
Hi Seth, thanks for your reply > * pre-generating a list of signed URLs and running them through httperf Could you explain this a bit more? How did you pre-generate URLs? Were you just testing use of the access token, or the full dance to obtain it? > I was thinking that it might be useful to hack OAuth support into > JMeter in order to be able to use that, but never got that far. Yeah, I was looking at doing this too. It should be possible to write a JMeter plugin, but I needed something a bit faster. What we ended up doing was using PLAINTEXT - with such a simple signing scheme it was reasonably easy to write load runner scripts. We are making the assumption that the extra computation required to do HMAC-SHA1 will not be significant compared to DBA access etc cheers Perryn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
