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