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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Chuck
Mortimore
Sent: Saturday, April 10, 2010 1:03 PM
To: Eran Hammer-Lahav; OAuth WG
Cc: apps-disc...@ietf.org
Subject: Re: [OAUTH-WG] Native applications capable of handling callbacks
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" <e...@hueniverse.com> wrote:
(+apps-discuss as this is of general interest to the area)
On 4/9/10 1:26 PM, "Chuck Mortimore" <cmortim...@salesforce.com> 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
> 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
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
