Subject: [OAUTH-WG] OAuth without HTTP redirects

From: Greg Brockman <[email-masked]>
Date: Thu, 17 Mar 2011 12:20:02 -0700

Hi,

I notice that the current OAuth2 draft seems to have browser redirects
baked in rather deeply.  Are there any plans to add support for flows
that don't involve HTTP redirects?  For example, it seems at the
moment that pure JavaScript applications aren't well-supported, as the
resource owner must be redirected to the authorization endpoint, thus
leaving the JS app.  Now of course trying to do the OAuth flow from
within the JS app (say by displaying the authorization endpoint within
an iframe) might expose phishing attacks, but one could imagine e.g. a
plugin that integrates with the browser in order to provide a
relatively unforgeable OAuth authorization endpoint.

More generally, does this sound like a use-case that OAuth would be
interested in supporting?

Thanks,

- gdb

(Reposting from [email-masked] as this seems a more appropriate forum.)

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Thu, 17 Mar 2011 16:31:06 -0500

The required binding of the client and refresh token is implied. For clarity, I would suggest to make it explcit with the following edits: 

+ In section 1.5, after the first sentence, add "Unlike the access token, the refresh token is bound to the client and is consumed only by the authorization server."

+ On p. 33, the sentence "The client includes its authentication credentials as described in Section 3" is descriptive. Make it prescriptive to read "The client MUST include its authentication credentials as described in Section 3."

Regards,
Huilan LU

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Mar 2011 00:06:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lu, Hui-Lan (Huilan)
> Sent: Thursday, March 17, 2011 2:31 PM
 
> The required binding of the client and refresh token is implied. For clarity, I
> would suggest to make it explcit with the following edits:
> 
> + In section 1.5, after the first sentence, add "Unlike the access token, the
> refresh token is bound to the client and is consumed only by the
> authorization server."

          The refresh token is bound to the
          client it was issued to, and its usage requires client authentication.
 
> + On p. 33, the sentence "The client includes its authentication credentials as
> described in Section 3" is descriptive. Make it prescriptive to read "The client
> MUST include its authentication credentials as described in Section 3."

Added instead:

        The authorization server MUST validate the client credentials, ensure that the refresh
        token was issued to the authenticated client, validate the refresh token, and
        verify that the resource owner's authorization is still valid.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 31 Mar 2011 18:34:56 -0700

Hi Greg,

Google is working on a pure JavaScript flow which does not involve redirects.

Marius

On Thu, Mar 17, 2011 at 12:20 PM, Greg Brockman <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>