Subject: [OAUTH-WG] native app support (was: Next draft)

From: Marius Scurtescu <[email-masked]>
Date: Tue, 8 Jun 2010 10:46:19 -0700

In order to properly support native applications I suggest the
following changes:

1. client_name

In all flows when client_id is sent also allow for an optional
client_name. This optional parameter is meant as a display name for
the client, and it is useful in all unregistered cases, not only for
native apps.

If the client is unregistered then most likely the authz server will
require that client_id be set to a predefined value like "anonymous".
The approval page does need a client name so it can tell the user who
it is granting access for.

2. optional redirect_uri (default result page)

Some native apps do not have a redirect_uri, as a result two things are needed:

2.1 Either make redirect_uri optional or define a standard value that
signals that the client does not have such a page.

2.2 The authz server must supply a default result page, if there is no
redirect_uri. Also, this page should put the verification code and the
client state (code and state) in the page title in a standard way such
that the native app can extract them from the window title. WRAP
defined how the title should be formed.

3. device flow should be able to start user-agent

The device flow can be used by native apps in which case there is a
browser on the device. This flow should be able to start a browser and
directly take the user to the end-user verification URI with the user
code added as a query parameter (so the user is not required to do any
manual entry). This is sort of possible right now, but the handler
behind verification_uri must expect an optional user_code (in which
case it should not prompt the user).

4. section with guidance for native apps

I think the spec needs a section that explains how native apps can be
used with OAuth 2. Not sure if it is worth getting into pros and cons
for each flow, but all flows can be used.

Marius

On Mon, Jun 7, 2010 at 8:44 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> I still need to catch up on the list (I took a little break). I plan to post a new draft this week incorporating many editorial changes discussed at the interim meeting. I am also planning of removing some non-stable features (such as discovery and signatures) from the draft and moving them to new drafts. As soon as -06 is published, I plan to issue informal last-calls for each section so that we can lock down the normative portions of the draft.
>
> If you have any must-happen changes for -05 that were not already posted to the list, please let me know.
>
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: David Recordon <[email-masked]>
Date: Tue, 8 Jun 2010 11:45:33 -0700

Hey Marius,

1) Feels like this should be in an unregistered client spec.

3) Why would a device which intends to open a web browser use the
device flow to start? Wouldn't it just use the user agent flow?

4) Yes, but should be a separate document.

Thanks,
--David

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 8 Jun 2010 13:28:38 -0700

> 1) Feels like this should be in an unregistered client spec.

Not sure. Does the core spec always assume registered?

> device flow to start? Wouldn't it just use the user agent flow?

Two reasons:
- User-Agent flow probably does not return a refresh token
- much harder to capture the response from User-Agent or Web Server
(embed browser, watch title, ...), with device flow all this goes away

> 4) Yes, but should be a separate document.

Maybe. Native apps are a main use case, more important than devices
IMO. Why keep devices in core and move out native apps?

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 09 Jun 2010 09:42:36 +0200

1) +1
2) +1 - Oauth 1.0a had "oob", why not for that purpose
3) I would rather add the user_code as optional URL parameter to the 
device flow.
4) What about an additional best practices document?

regards,
Torsten.

Am 08.06.2010 19:46, schrieb Marius Scurtescu:
> On Mon, Jun 7, 2010 at 8:44 AM, Eran Hammer-Lahav<[email-masked]>  wrote:
>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 9 Jun 2010 09:45:11 -0700

On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> 3) I would rather add the user_code as optional URL parameter to the device
> flow.

Are you suggesting the same thing? That the endpoint at
verification_uri should accept an optional user_code query parameter?

Marius

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 09 Jun 2010 18:57:36 +0200

Oops, I misread this point.

So +1 for 3), too.

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 22 Jun 2010 13:02:21 -0700

On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu <[email-masked]> wrote:
> [...]

Should this also go to an extension? It is not introducing any new
parameters, not sure if it belongs there. OAuth 1 at least defined the
"oob" special value.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Jun 2010 15:14:03 -0700

In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in the spec because it doesn't help interop. If the server supports such a scheme, it should document it. It also falls under "previously established redirection URI" which happens to point at the server.

EHL

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Tuesday, June 22, 2010 1:02 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: native app support (was: Next draft)
> 
> Should this also go to an extension? It is not introducing any new parameters,
> not sure if it belongs there. OAuth 1 at least defined the "oob" special value.
> 
> Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 22 Jun 2010 15:34:59 -0700

> In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in the spec because it doesn't help interop. If the server supports such a scheme, it should document it. It also falls und…

OK, that makes sense.

What about:
> Also, this page should put the verification code and the

Extension?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Jun 2010 16:07:24 -0700

> Sent: Tuesday, June 22, 2010 3:35 PM
> To: Eran Hammer-Lahav
> > In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in
> the spec because it doesn't help interop. If the server supports such a
> scheme, it should document it. It also falls under "previously established
> redirection URI" which happens to point at the server.
> 
> OK, that makes sense.
> 
> What about:
> > Also, this page should put the verification code and the client state
> > (code and state) in the page title in a standard way such that the
> > native app can extract them from the window title. WRAP defined how
> > the title should be formed.
> 
> Extension?

I don't think this needs a spec. Just something provided by the server. Does the client need any special handling? It can always just use a static web page to do this, no?

EHL

> >> > Some native apps do not have a redirect_uri, as a result two things
> >> > are
> >> needed:
> >> >
> >> > 2.1 Either make redirect_uri optional or define a standard value
> >> > that signals that the client does not have such a page.
> >> >
> >> > 2.2 The authz server must supply a default result page, if there is
> >> > no redirect_uri. Also, this page should put the verification code
> >> > and the client state (code and state) in the page title in a
> >> > standard way such that the native app can extract them from the
> >> > window title. WRAP defined how the title should be formed.
> >>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 22 Jun 2010 16:16:56 -0700

> I don't think this needs a spec. Just something provided by the server. Does the client need any special handling? It can always just use a static web page to do this, no?

A spec would help so all servers provide code and state in a
consistent format. Client libraries can then provide methods to parse
this. Also, client apps connecting to multiple servers can expect some
consistency.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Jun 2010 16:26:10 -0700

In that case, I suggest an extension. But I just don't think this needs it. Why involve the server at all in this? The client should just host a web page somewhere with the format it wants or the language for the user.

With $10 hosting, every client can host a web page somewhere.

EHL

> Sent: Tuesday, June 22, 2010 4:17 PM
> To: Eran Hammer-Lahav
> >> the spec because it doesn't help interop. If the server supports such
> >> a scheme, it should document it. It also falls under "previously
> >> established redirection URI" which happens to point at the server.
> >>
> >> OK, that makes sense.
> >>
> >> What about:
> >> > Also, this page should put the verification code and the client
> >> > state (code and state) in the page title in a standard way such
> > I don't think this needs a spec. Just something provided by the server. Does
> the client need any special handling? It can always just use a static web page
> to do this, no?
> 
> A spec would help so all servers provide code and state in a consistent
> format. Client libraries can then provide methods to parse this. Also, client
> apps connecting to multiple servers can expect some consistency.
> 
> Marius
> 
> >
> > EHL
> >
> >>
> >> Marius
> >>
> >> >
> >> > EHL
> >> >
> >> >> > Some native apps do not have a redirect_uri, as a result two
> >> >> > things are
> >> >> needed:
> >> >> >
> >> >> > 2.2 The authz server must supply a default result page, if there
> >> >> > is no redirect_uri. Also, this page should put the verification
> >> >> > code and the client state (code and state) in the page title in
> >> >> > a standard way such that the native app can extract them from
> >> >> > the window title. WRAP defined how the title should be formed.
> >> >>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Jun 2010 16:41:25 -0700

Write the spec then. It should be pretty short.

EHL

> Sent: Tuesday, June 22, 2010 4:31 PM
> To: Eran Hammer-Lahav
> On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav
> <[email-masked]> wrote:
> > In that case, I suggest an extension. But I just don't think this needs it. Why
> involve the server at all in this? The client should just host a web page
> somewhere with the format it wants or the language for the user.
> >
> Hard to tell, you could be right. Keep in mind that this page has to be reliable
> and secure, $10 will probably not give you that. An authz server can easily
> provide all this at almost no cost.
> 
> Marius
> 
> >
> > EHL
> >
> >> >> the spec because it doesn't help interop. If the server supports
> >> >> such a scheme, it should document it. It also falls under
> >> >> "previously established redirection URI" which happens to point at the
> server.
> >> >>
> >> >> OK, that makes sense.
> >> >>
> >> >> What about:
> >> the client need any special handling? It can always just use a static
> >> web page to do this, no?
> >>
> >> >> >> > In order to properly support native applications I suggest
> >> >> >> > the following changes:
> >> >> >> > [...]
> >> >> >> > 2.1 Either make redirect_uri optional or define a standard
> >> >> >> > value that signals that the client does not have such a page.
> >> >> >> >
> >> >> >> > 2.2 The authz server must supply a default result page, if
> >> >> >> > there is no redirect_uri. Also, this page should put the
> >> >> >> > verification code and the client state (code and state) in
> >> >> >> > the page title in a standard way such that the native app can
> >> >> >> > extract them from the window title. WRAP defined how the title
> should be formed.
> >> >> >>
> >> >> >> Should this also go to an extension? It is not introducing any
> >> >> >> new parameters, not sure if it belongs there. OAuth 1 at least
> >> >> >> defined the
> >> >> "oob" special value.
> >> >> >>
> >> >> >> Marius
> >> >> >
> >> >
> >

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 22 Jun 2010 16:30:52 -0700

> With $10 hosting, every client can host a web page somewhere.

Hard to tell, you could be right. Keep in mind that this page has to
be reliable and secure, $10 will probably not give you that. An authz
server can easily provide all this at almost no cost.

Marius

---

From: Luke Shepard <[email-masked]>
Date: Tue, 22 Jun 2010 23:00:53 -0700

Two points:

1/ I agree that it can be onerous for clients to host web pages. It's not a matter of expense but of complexity.

BUT

2/ As we discussed previously in our in-person meeting, this should be handled by a different endpoint, and not be the responsibility for the provider. If Google wishes to support this for their desktop apps, then it should provide an endpoint that handles the OAuth response and puts it in the <title>. I can say that Facebook has no interest in supporting this hack on the server side, but clients that want it can use their own html file that does it for them.

For example, for Javascript web apps it is a pain to host a cross-domain receiver file. So we host one on behalf of developers (called xd_proxy.php). But it is not part of our server-side logic.

If you want to write a spec for that, then great, but the <title> hack does not belong in the main spec.

---

From: Luke Shepard <[email-masked]>
Date: Wed, 23 Jun 2010 00:37:24 -0700

One more question - is the <title> technique used in production? I think you'd mentioned that it was ... if so, can you point me to the docs where it's currently used?

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 24 Jun 2010 13:19:58 -0700

> One more question - is the <title> technique used in production? I think you'd mentioned that it was ... if so, can you point me to the docs where it's currently used?

Google has several Windows desktop apps that use this technique. There
is an Outlook integration app called Glook and probably some versions
of Picasa and SketchUp.

Marius