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
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
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
On Sun, Jan 17, 2010 at 10:42 AM, Isaiah Carew <isa...@me.com> 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
> 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.
> 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?