Re: [OAUTH-WG] questions about implicit grant

[Justin Richer <[e-mail]>]

> 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