Subject: [OAUTH-WG] Native applications capable of handling callbacks

From: Chuck Mortimore <[email-masked]>
Date: Fri, 9 Apr 2010 13:26:02 -0700

A number of the modern application platforms (Android, iPhone, iPad) have support for registering custom url schemes for native applications.    This allows them to receive callbacks from web browsers, without resorting to copy paste, or window title polling.    For instance, the authorization server may redirect the devices browser to:

HTTP/1.1 302 Found
Location: myapp://oauth_callback?code=i1WsRn1uB1

This results in the application launching and the URL being passed to it's callback handler.

There are a few issues I see with handling these in current form:

 *   The Web Callback flow is not appropriate, as the client secret cannot be secured
 *   The Native Application flow best describes these types of clients, but doesn't handle the flow
 *   The User Agent flow would likely work, but the description would lead implementers away from this, and I'd be concerned that the implementations may gravitate towards handling cross domain javascript tunneling

I believe all of the pieces are here to support this, but I'd be interested in seeing stronger guidance for implementers on how to handle these clients.

- cmort

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 21:45:46 -0700

(+apps-discuss as this is of general interest to the area)

On 4/9/10 1:26 PM, "Chuck Mortimore" <[email-masked]> wrote:

> A number of the modern application platforms (Android, iPhone, iPad) have
> support for registering custom url schemes for native applications.    This
> allows them to receive callbacks from web browsers, without resorting to copy
> paste, or window title polling.    For instance, the authorization server may
> redirect the devices browser to:
> 
> HTTP/1.1 302 Found
> This results in the application launching and the URL being passed to it¹s
> callback handler.
> 
> * The Native Application flow best describes these types of clients, but
> doesn¹t handle the flow
> * The User Agent flow would likely work, but the description would lead
> implementers away from this, and I¹d be concerned that the implementations may
> gravitate towards handling cross domain javascript tunneling
> 
> I believe all of the pieces are here to support this, but I¹d be interested in
> seeing stronger guidance for implementers on how to handle these clients.
> 
> - cmort

The first problem with including this approach in an IETF specification is
that it indirectly violates IETF standards, namely the rules governing how
new URI schemes should be discussed, approved, and registered. This is also
of interest to the W3C TAG.

The way this should probably be done is by registering a new URN scheme like
app which will look something like:

app:application_name:comma_delimited_parameters

With application_name either a domain-name-namespaced value (e.g.
app:microsoft.com:excel:parameters) or registry based.

But without such a mechanism (feel free to offer other ideas), to suggest in
an IETF standard that developers should go and make up random URI schemes
for their clients is both bad policy and not likely to pass Last Call.

If this group has the appetite for such a feature, I would be happy to draft
a very short proposal for such a new URN scheme, which we can then publish
separately or include in the OAuth spec.

In practice, until companies like Apple and Microsoft (the two leading OS
vendors), and Google (with Android) support such a generic application URN,
people will continue to do so. But if we propose a standard path, we can
then mention the "abusive" practice and declare it deprecated, pointing
people to the right way of doing it. That will help in getting adoption long
term.

Thoughts?

EHL

---

From: Chuck Mortimore <[email-masked]>
Date: Sat, 10 Apr 2010 13:02:57 -0700

While I agree it's a bit of an abusive practice, it is a pervasive one, and I'm worried about our ability to actually change the behavior of these platforms ( Mozilla is in the list as well ).

So - it's a bit of a trade off.   I certainly don't want to add anything to the spec that won't get approved.  On the other hand, pragmatically, I'm mostly concerned with securing these devices and how my customer's credentials are used with them.    I know the pattern of usage emerged on-top of Oauth 1; I suspect it will emerge in Oauth2, so I'd be inclined to offer some guidance.

I'll defer to your advise on how best to handle it within the IETF and the spec...

-cmort

On 4/9/10 9:45 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

On 4/9/10 1:26 PM, "Chuck Mortimore" <[email-masked]> wrote:

> doesn't handle the flow
> implementers away from this, and I'd be concerned that the implementations may
> I believe all of the pieces are here to support this, but I'd be interested in

Thoughts?

EHL

---

From: Brian Eaton <[email-masked]>
Date: Mon, 12 Apr 2010 10:42:16 -0700

On Sat, Apr 10, 2010 at 1:02 PM, Chuck Mortimore
<[email-masked]> wrote:
> While I agree it’s a bit of an abusive practice, it is a pervasive one, and
> I’m worried about our ability to actually change the behavior of these
> platforms ( Mozilla is in the list as well ).
>
> So – it’s a bit of a trade off.   I certainly don’t want to add anything to
> the spec that won’t get approved.  On the other hand, pragmatically, I’m
> mostly concerned with securing these devices and how my customer’s
> credentials are used with them.    I know the pattern of usage emerged
> on-top of Oauth 1; I suspect it will emerge in Oauth2, so I’d be inclined to
> offer some guidance.
>
> I’ll defer to your advise on how best to handle it within the IETF and the
> spec...

Agreed.  This is a hard problem, and developers need guidance on what
kind of solutions work in practice.

---

From: Luke Shepard <[email-masked]>
Date: Wed, 14 Apr 2010 10:32:49 -0700

Sorry, I missed this thread. It dovetails with my objections raised in the other thread ("Combining the native application and user-agent flows")

The question of whether OAuth should support custom URL protocols seems a bit academic. In practice, major providers will probably allow them if there is demand from developers. The goal of this group is to establish a pragmatic, widely adopted authentication protocol - not to wage a IETF campaign against browser vendors to force compliance to standards.

Additionally, in my email I laid out a few ways for an entirely client app to handle a callback without using custom protocols. For instance:

-          Use a scheme like "about:blank" (does that count as a custom scheme or is it supported by the IETF?)

-          Host a static callback themselves. For many apps it's much easier to host a single, static callback than a dynamic server endpoint.

-          Use a callback hosted by the provider (i.e., http://facebook.com/universal_callback

In practice, this is how desktop and mobile clients work to access Facebook today. The Native Application flow is basically like  the third option above (callback hosted by provider), but without the flexibility of the first two. We should just get rid of that flow and use the "User-agent" flow. (I would prefer something like "Client-side App flow" but I understand that the naming here is pretty difficult)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chuck Mortimore
Sent: Saturday, April 10, 2010 1:03 PM
To: Eran Hammer-Lahav; OAuth WG
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks

-cmort

Thoughts?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 10:47:26 -0700

On 4/14/10 10:32 AM, "Luke Shepard" <[email-masked]> wrote:

> Sorry, I missed this thread. It dovetails with my objections raised in the
> other thread (³Combining the native application and user-agent flows²)
>  
> The question of whether OAuth should support custom URL protocols seems a bit
> academic. In practice, major providers will probably allow them if there is
> demand from developers. The goal of this group is to establish a pragmatic,
> widely adopted authentication protocol  not to wage a IETF campaign against
> browser vendors to force compliance to standards.

It's not a question of an "IETF campaign" but of what an IETF specification
can say about it. WRAP explicitly mentions custom URI schemes which is
something we cannot do in an IETF spec because clearly violates IETF
standards.

The questions are "do we want to mention custom URI schemes? Do we think it
is a useful pattern?" and I suspect the answer is yes given how widely this
technique is used on the iPhone and other platforms. So then the question is
how to do this within the context of an IETF specification or leave it for
people to figure out on their own (or in books and articles).

Creating a scheme for this isn't hard and is one simple way to accomplish
the same thing. It also allows us to mention how it is done today and
encourage people to seek the other way when possible. This is how we make
progress in standards (document the bad practice and offer better
solutions).

> Additionally, in my email I laid out a few ways for an entirely client app to
> handle a callback without using custom protocols. For instance:
> -         Use a scheme like ³about:blank² (does that count as a custom scheme
> or is it supported by the IETF?)

There is a proposed RFC for 'about:' but it seems stuck due to lack of
authors time.

> -         Host a static callback themselves. For many apps it¹s much easier to
> host a single, static callback than a dynamic server endpoint.

I assume you mean host a fixed document on a server.

> http://facebook.com/universal_callback

Sure, as long as it doesn't end up as an open redirector with the known
security issues.

> In practice, this is how desktop and mobile clients work to access Facebook
> today. The Native Application flow is basically like  the third option above
> (callback hosted by provider), but without the flexibility of the first two.
> We should just get rid of that flow and use the ³User-agent² flow. (I would
> prefer something like ³Client-side App flow² but I understand that the naming
> here is pretty difficult)

If we end up with one flow, I am sure I can come up with another name.

EHL

---

From: Luke Shepard <[email-masked]>
Date: Thu, 15 Apr 2010 16:09:05 -0700

Thanks for the response Eran, that helps clarify things.

I'm hoping to have some in-person discussions with some Googlers tomorrow to hopefully sort out the technical details of these flows. Will report back to the list with any findings.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Thursday, April 15, 2010 10:47 AM
To: Luke Shepard; OAuth WG
Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks

EHL