Technical Summary
The OAuth 2.0 authorization protocol enables a third-party
application to obtain limited access to an HTTP service, either
on behalf of a resource owner by orchestrating an approval
interaction between the resource owner and the HTTP service,
or by allowing the third-party application to obtain access on
its own behalf. This specification replaces and obsoletes the
OAuth 1.0 protocol described in RFC 5849.
Working Group Summary
There have been a number of controversies over the course
of the development of OAuth 2.0. All were eventually worked
out to the satisfaction of the working group as a whole, and the
result has significant consensus in the group, but some of it
hasn't been easy. The native application scenario (see section 9)
remains a significant point in question: applications that users
install -- perhaps may be convinced to install by malefactors -- are
always a difficult security point, and that is true with OAuth as
well. As the text in the document says, these "may require
special consideration", particularly in regard to security.
Because OAuth is trying to tie together applications and services
from different trust domains, and because it is relying on end
users to make important decisions, largely based on what they're
told by the user interfaces, there are an extraordinary set of
possible threats and security considerations involved. The working
group has chosen to handle this with a Security Considerations
section that covers general issues and focuses on protocol issues,
and a separate document (draft-ietf-oauth-v2-threatmodel) that
describes detailed threats and further security considerations in
more depth than would be possible in the base protocol spec.
There has been a great deal of discussion about where the line
is -- what should go into the Security Considerations (section 10)
in the base spec, and what will be in the companion document
(to which there is an informative reference at the beginning of
section 10).
In the end, the current text reflects strong working group
consensus, though it is not without disagreement. The working
group believes the two documents together do the right job, they
continue to work on draft-ietf-oauth-v2-threatmodel, and they
expect to complete that document within the next months.
Document Quality
There has been fairly broad deployment of OAuth 1.0, from
such companies as Yahoo!, Facebook, Google, and Twitter, and
many of the existing deployments have been keeping up with
the OAuth 2.0 progress, and adjusting their implementations
accordingly. Quite a number of working-group participants have
given the current spec very thorough review.
Personnel
Derek Atkins is the document shepherd.
Stephen Farrell is the responsible AD.
RFC Editor Note
none