Torsten, > Agreed. So what is then the benefit of the approach you > proposed with respect to native apps?
Do you mean why didn't I just choose one of the approaches in section 2.3 or the OAuth spec? Here is what the spec says: (now quoting from the spec) > Native application clients can be implemented in different > ways based on their requirements and desired end-user > experience. Native application clients can: > > o Utilize the end-user authorization endpoint as described in > Section 4 by launching an external user-agent. The > client can capture the response by providing a > redirection URI with a custom URI scheme (registered > with the operating system to invoke the client > application), This seems to be saying that the user's machine has a Web server running on it which is reachable from the Internet by sending an http request to the redirection URI. That's unrealistic because the user's machine won't typically have a permanent IP address reachable from the internet. > or by providing a redirection URI > pointing to a server-hosted resource under the > client's control That's what you are objecting to. > which makes the response available to > the client (e.g. using the window title or other > locations accessible from outside the user-agent). This is not pretty (besides the fact that is uses an ancillary server). > o Utilize the end-user authorization endpoint as described in > Section 4 by using an embedded user-agent. The client > obtains the response by directly communicating with the > embedded user-agent. With this method the application can sniff the user's credentials when the user authenticates to the authorization server, since it controls the embedded agent. So this method does not meet the original goal of OAuth, which was to not give the user's credentials to the client application; whereas the method used in PKAuth does. > Prompt end-users for their password and use them directly to > obtain an access token. This is generally discouraged, as > it hands the end-user's password directly to the third-party > client which in turn has to store it in clear-text. It also > requires the server to support password-based > authentication. Again, this fails to meet the original goal of OAuth. Regards, Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
