Subject: Re: [OAUTH-WG] unregistered applications

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 04 Jan 2011 23:12:29 +0100

Francisco,

just to make sure I understood your paper correctly: even native clients 
are required to have a backend server component, which receives the 
authorization results and makes it available to the native client?

regards,
Torsten.
> Hi all,
>
> OAuth provides only weak security when used with
> unregistered applications.  OTOH compulsory registration is
> a bad idea: imagine a situation where a social site becomes
> dominant, social login via that site becomes the de facto
> authentication standard on the Web, every application has to
> register with the site, and the site can kill any
> application by revoking its registration.  I've written a
> paper <http://www.pomcor.com/whitepapers/PKAuth.pdf> that proposes a 
> solution.  Thanks in advance for any
> comments.
>
> -- Francisco
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 17:18:33 -0800 (PST)

--- On Tue, 1/4/11, Torsten Lodderstedt <[email-masked]> wrote:
> just to make sure I understood your paper correctly: even
> native clients are required to have a backend server
> component, which receives the authorization results and
> makes it available to the native client?

Yes, a very simple one that responds to an http post request
by copying the body of the post to the body of the response.
(That could be done, for example, by a simple
application-independent Apache module.  Apache would be
configured to invoke the module for requests that target the
redirection uri, and send the response with a media type
that is handled by the native client application.)  These
days every little neighbourhood store as a Web site, so it
is safe to assume that the provider of the native client
application has one.

Francisco

---

From: [email-masked]
Date: Wed, 5 Jan 2011 06:15:23 +0000

These also means the availabilty of the native app on a device depends on the availabilty of this backend service. I don't know whether the average store website has a reasonable availability.

Regards,
Torsten.

Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: Francisco Corella <[email-masked]>
Date: Tue, 4 Jan 2011 17:18:33 
To: Torsten Lodderstedt<[email-masked]>
Reply-To: [email-masked]
Cc: <[email-masked]>; Karen P. Lewison<[email-masked]>
Subject: Re: [OAUTH-WG] unregistered applications

Francisco

---

From: [email-masked]
Date: Wed, 5 Jan 2011 06:29:21 +0000

Another question: how does the server validate the identity/authenticity of the client? In other words, what does a malicious app prevent from using the URL and server of another native app?

Regards,
Torsten.

---

From: Francisco Corella <[email-masked]>
Date: Wed, 5 Jan 2011 11:24:06 -0800 (PST)

Torsten,

> Another question: how does the server validate the
> identity/authenticity of the client? In other words, what
> does a malicious app prevent from using the URL and server
> of another native app?

Let me rephrase your question (correct me if I'm wrong): can
a malicious native app obtain an authcode that the user has
granted to a legitimate native app, by using the ancillary
server of the legitimate app?  The answer is yes, but only
if the user installs the malcious app on his/her own
machine, in which case there can be no security.  The
authcode is downloaded to the browser that was used for user
authentication, and it is delivered by the browser to an
application running on the same machine.

(From an earlier message...)
> These also means the availabilty of the native app on a
> device depends on the availabilty of this backend service. I
> don't know whether the average store website has a
> reasonable availability.

Availability is not a problem these days.  We use virtual servers 
on the Amazon cloud, which are very cheap, and availability is 
practically 100%.

Regards,

Francisco

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 05 Jan 2011 22:18:33 +0100

Francisco,
> application running on the same machine.

Agreed. So what is then the benefit of the approach you proposed with 
respect to native apps?

> on the Amazon cloud, which are very cheap, and availability is

Good point. Nevertheless, it is an extra burden to the developer of an 
native app.

regards,
Torsten.

---

From: Francisco Corella <[email-masked]>
Date: Wed, 5 Jan 2011 14:55:30 -0800 (PST)

Torsten,

> Agreed. So what is then the benefit of the approach you
> proposed with respect to native apps? 

Do you mean why didn't I just choose one of the approaches
in section 2.3 or the OAuth spec?  Here is what the spec
says:

(now quoting from the spec)

> Native application clients can be implemented in different
> ways based on their requirements and desired end-user
> experience.  Native application clients can:
> 
> o Utilize the end-user authorization endpoint as described in
> Section 4 by launching an external user-agent.  The
> client can capture the response by providing a
> redirection URI with a custom URI scheme (registered
> with the operating system to invoke the client
> application), 

This seems to be saying that the user's machine has a Web
server running on it which is reachable from the Internet by
sending an http request to the redirection URI.  That's
unrealistic because the user's machine won't typically have
a permanent IP address reachable from the internet.

> or by providing a redirection URI
> pointing to a server-hosted resource under the
> client's control 

That's what you are objecting to.

> which makes the response available to
> the client (e.g. using the window title or other
> locations accessible from outside the user-agent).

This is not pretty (besides the fact that is uses an
ancillary server).

> o Utilize the end-user authorization endpoint as described in
> Section 4 by using an embedded user-agent.  The client
> obtains the response by directly communicating with the
> embedded user-agent.

With this method the application can sniff the user's
credentials when the user authenticates to the authorization
server, since it controls the embedded agent.  So this
method does not meet the original goal of OAuth, which was
to not give the user's credentials to the client
application; whereas the method used in PKAuth does.

> Prompt end-users for their password and use them directly to
> obtain an access token.  This is generally discouraged, as
> it hands the end-user's password directly to the third-party
> client which in turn has to store it in clear-text.  It also
> requires the server to support password-based
> authentication.

Again, this fails to meet the original goal of OAuth.

Regards,

Francisco

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 5 Jan 2011 15:13:53 -0800

> a permanent IP address reachable from the internet.

For custom schemes you don't need a local web server.

You can also use a local web server, no routable/permanent IP is
needed. The authorization server can redirect to localhost perfectly
fine.

Marius

---

From: Francisco Corella <[email-masked]>
Date: Wed, 5 Jan 2011 19:01:16 -0800 (PST)

> needed. The authorization server can redirect to localhost perfectly

Ah, ok.  I'm not familiar with custom schemes, but I do
understand that you can redirect to localhost.  Thanks for
the explanation.

Francisco

---

From: Dick Hardt <[email-masked]>
Date: Wed, 5 Jan 2011 19:09:07 -0800

> understand that you can redirect to localhost.  Thanks for

An example of a custom scheme would be what Pounce popularized on the iPhone. 
A redirect to pounce:// would load the Pounce app and pass in the URL

-- Dick

---

From: Francisco Corella <[email-masked]>
Date: Thu, 6 Jan 2011 13:32:11 -0800 (PST)

Dick,

> A redirect to pounce:// would load the Pounce app and pass in the URL

Thanks for the tip!  I'll have to look at how custom schemes are used on iOS.

Francisco