I've read a few comments on this DL that a primary goal is that writing an OAuth 2.0 client should be very easy. I think we're doing well here. I know this ease for the client necessarily comes at the expense of some complexity on the server. As has also been pointed out recently (by Eran, I believe) the AS' job is considerably more complex now than it was in OAuth 1.0.
While overall this *may* be a win, it also seems optimized for the few large service providers that are driving the spec (Facebook, Twitter, etc.). They definitely have the resources and understanding that a large investment in security is important. But as more web sites across the Internet drop using user passwords in favor of federated identity and/or OpenID-type protocols, the only way these sites can delegate access to user data will be to use a protocol like OAuth 2.0 since user passwords will no longer apply. Therefore *very *many web sites will become OAuth 2.0 resource servers, and likely given their size and requirements will be their on authorization server as well. Now we have a complex server-side protocol that may be "too" complex for the average-sized web site to implement correctly and confidently. So my $0.02 here is that we try to keep the AS side simple as well where possible. And invite responses from others. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
