Subject: [OAUTH-WG] questions about implicit grant

From: John Joseph Bachir <[email-masked]>
Date: Mon, 14 Nov 2011 21:43:12 -0500

I have a few questions about the implicit grant type. Let me know if this
is covered in documentation.

The spec says that this grant type is "optimized for public clients known
to operate a particular redirection URI".
(a) What does "public" mean here? In what sense could a client be public or
private, and why is implicit grant more appropriate for the public case?
(b) What does "a particular redirection URI" mean? The role of the redirect
URI and expectations of how it is handled are identical to the code type,
right?

The potential appeal of this flow to me is the reduction of steps in the
case where there is only one type of token needed which does not need to be
refreshed. In section 4.2 of the spec [1], steps A, B, and C where exactly
what I expected. However:
(a) I don't understand the use case for D, E, and F, and I couldn't find
any discussion of this on the web.
(b) Moreover, I don't understand why D, E, and F would ever be necessary,
because the access token is already sent directly to the client in step C.

Thanks!
John

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.2

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Nov 2011 08:57:57 -0500

> The spec says that this grant type is "optimized for public clients
> known to operate a particular redirection URI".
> (a) What does "public" mean here? In what sense could a client be
> public or private, and why is implicit grant more appropriate for the
> public case?

Section 2.1, client types.

> (b) What does "a particular redirection URI" mean? The role of the
> redirect URI and expectations of how it is handled are identical to
> the code type, right?

Since you can't reliably bake a secret into a public client, you can't
rely on it to validate the client. However, if you are using a trusted
and pre-registered redirection URL, then you are very effectively
identifying the client. A bad actor wouldn't use someone else's redirect
URL because they'd never get the callback.

> The potential appeal of this flow to me is the reduction of steps in
> the case where there is only one type of token needed which does not
> need to be refreshed. In section 4.2 of the spec [1], steps A, B, and
> C where exactly what I expected. However:
> (a) I don't understand the use case for D, E, and F, and I couldn't
> find any discussion of this on the web.
> (b) Moreover, I don't understand why D, E, and F would ever be
> necessary, because the access token is already sent directly to the
> client in step C.

Step C is the server sending back the HTTP redirect in response to step
A. Steps D, and E are the user agent following that HTTP redirect. Step
F is extracting the information from the redirected endpoint. While the
access token is sent back in step C, scripts running in the user agent
don't have easy access to it.

 -- Justin

---

From: John Joseph Bachir <[email-masked]>
Date: Tue, 15 Nov 2011 12:41:16 -0500

Thanks Justin - some more questions below...

> > What does "public" mean here? In what sense could a client be

My understanding of a public client from this section was a client which is
distributed and not hosted on a server, such as a desktop or mobile app.
How is it possible for a web-hosted client to be public?

> don't have easy access to it.

Ah whoops, I misread C and D. So here's my real question: Why doesn't the
user agent send the access token to the server in D? Why does the web
server have to deliver a script which extracts it locally? Is it to
facilitate a certain style of applications development?

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Nov 2011 13:00:11 -0500

> 
> My understanding of a public client from this section was a client
> which is distributed and not hosted on a server, such as a desktop or
> mobile app. How is it possible for a web-hosted client to be public?

In a JavaScript client, all of the code is distributed to the end user's
machine to execute locally, as opposed to a server-side script which
only shows the browser its output. In order for JS in the browser to
have a secret, the server that hosts the JS would need to spit out the
secret along with the code. This secret would likely be the same for
every instance of the JS client, and it would be readable by the end
user of all of them, which makes it not really a secret and not really
very useful.

> Ah whoops, I misread C and D. So here's my real question: Why doesn't
> the user agent send the access token to the server in D? Why does the
> web server have to deliver a script which extracts it locally? Is it
> to facilitate a certain style of applications development?

1) The browser generally doesn't send the fragment to the web server

2) That's just standard deployed practice for such JS clients, and it's
currently the easiest way for the JS to get a ping that the transaction
has completed. 

 -- Justin

---

From: John Joseph Bachir <[email-masked]>
Date: Tue, 15 Nov 2011 13:28:09 -0500

Okay, so I think the basic thing I'm not getting is: what's the use case
for a javascript client? Googling doesn't help much here...

---

From: Dan Taflin <[email-masked]>
Date: Tue, 15 Nov 2011 20:26:00 +0000

I’ve spent the last couple months trying to answer this question myself (even posted on Stack Overflow, http://stackoverflow.com/questions/7522831/what-is-the-purpose-of-the-implicit-grant-authorization-type-in-oauth-2), and here’s the best answer I can come up with: it’s a great solution for someone like, say, Facebook or Twitter to be able to hand out a blob of javascript and say, “Here, put this on your web page to enable users to like/tweet/post on their account.” The 3rd-party web site doesn’t have to write a lick of oauth code to manage the authorization process – the access token just magically becomes available in the javascript code.

Dan

On 11/15/11 10:28 AM, "John Joseph Bachir" <[email-masked]> wrote:

Okay, so I think the basic thing I'm not getting is: what's the use case for a javascript client? Googling doesn't help much here...

---

From: John Joseph Bachir <[email-masked]>
Date: Tue, 15 Nov 2011 16:40:29 -0500

On Tue, Nov 15, 2011 at 3:26 PM, Dan Taflin <[email-masked]>wrote:

> it’s a great solution for someone like, say, Facebook or Twitter to be
> able to hand out a blob of javascript and say, “Here, put this on your web
> page to enable users to like/tweet/post on their account.” The 3rd-party
> web site doesn’t have to write a lick of oauth code to manage the
> authorization process – the access token just magically becomes available
> in the javascript code.

Ah ha! It all makes sense now. I even know the mechanics of Facebook in
that case but didn't make the connection.

I wonder how the description in the spec could be tweaked a bit to maybe
explain this better.