> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
