Subject: Re: [OAUTH-WG] Native Client Extension

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

+1

I have asked myself all the time why "oob" disappeared in OAuth 2.0? 
Does Google use this feature?

regards,
Torsten.
Am 29.12.2010 23:53, schrieb Marius Scurtescu:
> I would like to propose an OAuth 2 extension that helps native clients
> close the loop after the approval page. The extension defines a
> special value for the redirect URI for the case when the client does
> not have such a URI and it also defines that the authorization server
> should provide a default result page for this case and how to format
> the result on this page.
>
> If a native client does not have a redirect URI then the client can
> specify the special value "oob" for that parameter.
>
> redirect_uri=oob signals to the authorization server that it should
> use a default result page to show the final result.
>
> In this case the authorization server cannot redirect any kind of
> messages back to the client, not even error responses.
>
> The default result page should show the authorization code (code) and
> instruct the user to copy to native application.
>
> The default result page should also show both the authorization code
> and the passed through client state (state) in the page title, the two
> parameters should be form-encoded and appear space separated at the
> end of the normal title
>
> Example page title:
> <title>Success code=123456&state=qwerty</title>
>
> Browsers will truncate the title at some browser and OS dependent
> length. Ideally the whole title should be shorter than 100 characters.
> The Authorization Server should use a short title prefix and it should
> make the authorization codes as short as possible. Native clients
> should try to pass very short state strings and only of really needed.
>
> If the user denies, or there are other errors, the default page should
> similarly display the error code and also put the error message in the
> title:
> <title>Denied error=access_denied&state=qwerty</title>
>
> References:
>      * Section 6.3.3.2 of draft-hardt-oauth-wrap-01
>
>
> If there is interest and rough consensus then I can create a formal
> version of this extension.
>
>
> Thanks,
> Marius
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 4 Jan 2011 14:58:29 -0800

On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> +1
>
> I have asked myself all the time why "oob" disappeared in OAuth 2.0? Does
> Google use this feature?

Yes, we are planning to support this, exactly as described in the extension.

Marius

---

From: Skylar Woodward <[email-masked]>
Date: Thu, 27 Jan 2011 12:00:14 +0100

Marius,

I support the extension (as per my previous letter, as I missed this thread over the holidays) and Kiva is/was planning to support this as well.  Given the unpredictable technology environments of many of our customers, this flow is essential for our implementation.

However, now reviewing language in draft-12, I wonder if it isn't more clear to define the extension as using a different response_type (eg, oob_code).  In the past, the use of "oob" has been more of hack to work with existing specs. In truth, it is a unique flow of its own compared to Implict and Auth Code as they are currently defined.  Such a flow would not accept a redirect_url and could use "oob_code" for both response_type and grant_type.

skylar

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 27 Jan 2011 14:39:54 -0500

+1 on out of band auth being moved to a more fully-specified extension. It can (and likely should) still use mechanisms such as auth codes, but with different requirements such as no return URL. This is where things like the <title>code</title> hack can live, as well.

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Skylar Woodward [[email-masked]]
Sent: Thursday, January 27, 2011 6:00 AM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Native Client Extension

Marius,

skylar

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 27 Jan 2011 13:02:07 -0700

I think it should still use the existing 'token' and 'code' values, but with a special redirect_uri value (preferably something like a urn: to make it clear). This way, there is no need to add a new mechanism for extending parameter *values* (though such an extension *can* update the registration of the 'response_type' parameter), no need for special rules about the redirect_uri parameters, and the urn: can be used to indicate the style of the delivery (title, custom scheme, etc.). It also allows using both redirection-based flows.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Richer, Justin P.
> Sent: Thursday, January 27, 2011 11:40 AM
> To: Skylar Woodward; Marius Scurtescu
> Cc: OAuth WG
> +1 on out of band auth being moved to a more fully-specified extension. It
> can (and likely should) still use mechanisms such as auth codes, but with
> different requirements such as no return URL. This is where things like the
> <title>code</title> hack can live, as well.
> 
>  -- Justin
> I support the extension (as per my previous letter, as I missed this thread
> over the holidays) and Kiva is/was planning to support this as well.  Given the
> unpredictable technology environments of many of our customers, this flow
> is essential for our implementation.
> 
> However, now reviewing language in draft-12, I wonder if it isn't more clear
> to define the extension as using a different response_type (eg, oob_code).
> In the past, the use of "oob" has been more of hack to work with existing
> specs. In truth, it is a unique flow of its own compared to Implict and Auth
> Code as they are currently defined.  Such a flow would not accept a
> redirect_url and could use "oob_code" for both response_type and
> grant_type.
> 
> skylar
> 
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 27 Jan 2011 16:44:39 -0800

> However, now reviewing language in draft-12, I wonder if it isn't more clear to define the extension as using a different response_type (eg, oob_code).  In the past, the use of "oob" has been more…

I still think that "oob" applies only to the mechanism to return a
result, and not to the whole flow. Theoretically redirect_uri=oob
should work with both response_type=code and response_type=token, but
I had in mind only code.

Also, I don't see a reason to do anything special with the grant_type,
once the client has an authorization code it is all the same.

Marius

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 28 Jan 2011 13:09:16 +0100

I agree in terms of simplicity, but the language in 4.1 and in the definition of redirect_url conflicts with group consensus. So it seems a single exception should be called out for the case where redirect_url=oob (or some compliant absolute url like x-oauth-oob:), or there should be an extension defined that makes this exceptional case clearly defined to co-exist with the core language of MUST, REQUIRED, and absolute.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 09:21:43 -0700

Why not:

urn:ietf:wg:oauth:2.0:oob

Can you can add more flavors for different ways of floating the token/code up to the application. This requires no changes at all to -12 to allow this special case.

EHL

> Of Skylar Woodward
> Sent: Friday, January 28, 2011 4:09 AM
> To: Marius Scurtescu
> Cc: OAuth WG
> I agree in terms of simplicity, but the language in 4.1 and in the definition of
> redirect_url conflicts with group consensus. So it seems a single exception
> should be called out for the case where redirect_url=oob (or some compliant
> absolute url like x-oauth-oob:), or there should be an extension defined that
> makes this exceptional case clearly defined to co-exist with the core
> language of MUST, REQUIRED, and absolute.
> 
> >> However, now reviewing language in draft-12, I wonder if it isn't more
> clear to define the extension as using a different response_type (eg,
> oob_code).  In the past, the use of "oob" has been more of hack to work
> with existing specs. In truth, it is a unique flow of its own compared to Implict
> and Auth Code as they are currently defined.  Such a flow would not accept a

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 28 Jan 2011 10:07:07 -0800

> Can you can add more flavors for different ways of floating the token/code up to the application. This requires no changes at all to -12 to allow this special case.

Using the simpler "oob" does require changes to the core spec? Why?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 11:25:50 -0700

-12 3.1.1:

   The redirection URI MUST be an absolute URI and MAY include a query
   component, which MUST be retained by the authorization server when
   adding additional query parameters.

'oob' is not an absolute URI.

EHL

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Friday, January 28, 2011 10:07 AM
> To: Eran Hammer-Lahav
> Cc: Skylar Woodward; OAuth WG
> > Can you can add more flavors for different ways of floating the token/code
> up to the application. This requires no changes at all to -12 to allow this
> special case.
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 28 Jan 2011 11:24:54 -0800

Good point, I missed the absolute part. Thanks for pointing this out.

Let me think about it, the URN you suggested is a good start.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 12:34:09 -0700

If like many people, URN's give you an allergic reaction, you can also consider:

http://oauth.net/2.0/redirection/oob

Or something like that. The advantage of the URN is that if the server doesn't support this, it doesn't end up sending the user to oauth.net... ;-)

EHL

> Sent: Friday, January 28, 2011 11:25 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG

---

From: Skylar Woodward <[email-masked]>
Date: Sun, 30 Jan 2011 19:53:07 +0100

I was also thinking providers could specify a redirect_url on their own domain, such as

	http://www.kiva.org/oauth/callback/oob

But an urn or custom scheme (either is fine) that everyone can agree upon would my preference, primarily to reduce developer confusion, but similarly for the potential of false redirects that Eran mentions.