Re: [twitter-dev] OAuth best practice
Let's look at the current set of alternatives: 1) bop over to the browser on your mobile get out your pen, etc, write down that pin... 2) provide a simple user/pass interface within your app, and use HTTP basic, a scheme that gives a reasonable UX but from a security standpoint merits jail time. Both suck. I agree with their POV for the laptop/desktop environment, but it is important to find a way to do better for mobile. HTTP Digest might be a good step toward killing HTTP Basic usage. Perhaps it is time for a better oath (or something else) that will work with mobile? It might be more tolerable to be pitched to the browser if the pin copy could be eliminated. Maybe the twitter server could hold some sort of ticket state that the app could silently fetch after the user re-launches the app. On Sun, Jan 17, 2010 at 10:42 AM, Isaiah Carew wrote: > > Although you can find many instances of popular applications that do > exactly this, and the precise reasons for it being verboten are definitely > arguable and murky at best, the reaction that you'll receive from the OAuth > community is likely to be crystal clear, and very negative. > > I posted an open source app that did this and received this from a founding > member of the OAuth committee: > "...this approach is specifically one that OAuth is trying to protect users > from. > The problem is that your app does not (and can not) give users any trust > that you (or more importantly, an attacker) are not storing their Twitter > credentials without informing them..." > > My personal feelings about the veracity of this statement aside, the tone > is pretty clear: you shouldn't do this. > > isaiah > http://twitter.com/isaiah > > On Jan 17, 2010, at 8:50 AM, eco_bach wrote: > > > I'd like to embed the Twitter OAuth authorization-sign in window > WITHIN my application. > > Is this considered a best practice, or is it always recommended to > send the user to a new browser window for the service provider(Twitter > in this case) OAuth authentication process? > > >
Re: [twitter-dev] OAuth best practice
best practice for certain environments, certainly. On Sun, Jan 17, 2010 at 10:46 AM, Abraham Williams <4bra...@gmail.com>wrote: > It is best practice to always send the user to Twitter in their browser of > choice not embedded in another webpage/application. > > Abraham > > > On Sun, Jan 17, 2010 at 08:50, eco_bach wrote: > >> >> I'd like to embed the Twitter OAuth authorization-sign in window >> WITHIN my application. >> >> Is this considered a best practice, or is it always recommended to >> send the user to a new browser window for the service provider(Twitter >> in this case) OAuth authentication process? >> > > > > -- > Abraham Williams | Moved to Seattle | May cause email delays > Project | Intersect | http://intersect.labs.poseurtech.com > Hacker | http://abrah.am | http://twitter.com/abraham > This email is: [ ] shareable [x] ask first [ ] private. > Sent from Seattle, WA, United States >
Re: [twitter-dev] OAuth best practice
Although you can find many instances of popular applications that do exactly this, and the precise reasons for it being verboten are definitely arguable and murky at best, the reaction that you'll receive from the OAuth community is likely to be crystal clear, and very negative. I posted an open source app that did this and received this from a founding member of the OAuth committee: "...this approach is specifically one that OAuth is trying to protect users from. The problem is that your app does not (and can not) give users any trust that you (or more importantly, an attacker) are not storing their Twitter credentials without informing them..." My personal feelings about the veracity of this statement aside, the tone is pretty clear: you shouldn't do this. isaiah http://twitter.com/isaiah On Jan 17, 2010, at 8:50 AM, eco_bach wrote: > > I'd like to embed the Twitter OAuth authorization-sign in window > WITHIN my application. > > Is this considered a best practice, or is it always recommended to > send the user to a new browser window for the service provider(Twitter > in this case) OAuth authentication process?
Re: [twitter-dev] OAuth best practice
This brings up a really good point about OAuth. The reality is that when you put a really nice UI in front of OAuth on a mobile or in an application, you are very likely to make the direct credentials available to the application itself. In many cases, there is no memory access protection standing in the way. I agree that HTTP Basic auth is as bad as anything could ever be, putting the password on the wire. Has twitter thought about allowing HTTP Digest? It would eliminate the UX clunk, and still keep the passwords off the wire. On Sun, Jan 17, 2010 at 8:50 AM, eco_bach wrote: > > I'd like to embed the Twitter OAuth authorization-sign in window > WITHIN my application. > > Is this considered a best practice, or is it always recommended to > send the user to a new browser window for the service provider(Twitter > in this case) OAuth authentication process? >
Re: [twitter-dev] OAuth best practice
It is best practice to always send the user to Twitter in their browser of choice not embedded in another webpage/application. Abraham On Sun, Jan 17, 2010 at 08:50, eco_bach wrote: > > I'd like to embed the Twitter OAuth authorization-sign in window > WITHIN my application. > > Is this considered a best practice, or is it always recommended to > send the user to a new browser window for the service provider(Twitter > in this case) OAuth authentication process? > -- Abraham Williams | Moved to Seattle | May cause email delays Project | Intersect | http://intersect.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
