One security advantage of oauth with desktop apps is allowing the
application to keep you logged in
without having to store your password in plaintext on the hard disk. This
way if the computer is compromised or stolen later on your password is not

I still think the UX with desktop based oauth apps isn't the most joyful and
could be improved upon. One possible solution that has been brought up is
allowing the desktop app to "authorize" on your behalf using your username
and password. This way the app can get the access token without the user
having to visit the SP's site. Once the access token has been retrieved the
application can "forget" the password and remain logged in even if the
password changes in the future. All resource requests would then be done
using oauth with the access token.

Overall I think OAuth is a good solution for API authentication. Its secure
and provides benefits to the user, consumer, and sp.

On Fri, Jul 31, 2009 at 9:41 AM, Christopher St John <>wrote:

> On Thu, Jul 30, 2009 at 6:07 PM, Bradley S.
> O'Hearne<> wrote:
> >
> > I really want to hear stated, or read on a FAQ, is the pre-requisite
> > security trust, that in that scenario, it necessarily makes OAuth
> > superior to basic authentication.
> >
> The problem here is that you're paying attention, instead
> of just accepting "oauth is better because it is!" statements :-)
> For desktop apps (and in any case where the application has
> has control of the UI and/or your computer) OAuth has no
> security advantage (since the app can snoop the interaction)
> I'm sure bad people are working on a way to make this true
> in  browser apps as well, but I don't know of any examples.
> For web applications, many commentators acknowledge an
> increased risk of phishing as a potential problem with OAuth,
> although I haven't personally read any studies that indicate
> whether it's a theoretical or practical problem at this point.
> In any case, the primary benefit in OAuth is not protecting
> the user immediately from an evil application (since the
> authorization tokens an OAuth server hand out are just as
> powerful as passwords and must be protected like passwords)
> it's that:
>  - the owners of the service can (in theory) administratively
>  ban an application without forcing all the users to change
>  their passwords (a potentially very big benefit, maybe the
>  single benefit that justifies the general inconvenience)
>  - an individual user can ban an application by revoking its
>  authz token without having to change their password (a
>  moderate-at-best benefit, since you could always just
>  change your password)
>  - an individual who is using exactly the same password
>  at many sites doesn't have to expose out their mono-password
>  to an app (people mention this a lot, but come on, should
>  security system try to make people feel better about hitting
>  themselves on the head with a hammer? but this gets
>  mentioned a lot, so there you go)
> So, the security picture is actually a little fuzzy. There are
> some big wins for service administrators, some real (but
> medium-sized?) wins for users, some fundamental limits
> of applicability (web-apps only) and some open questions
> about phishing and snooping. And lots and lots of hype :-)
> -cks
> --
> Christopher St. John


Reply via email to