draft-ietf-oauth-v2-30.txt   draft-ietf-oauth-v2-31.txt 
OAuth Working Group D. Hardt, Ed. OAuth Working Group D. Hardt, Ed.
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 5849 (if approved) D. Recordon Obsoletes: 5849 (if approved) July 31, 2012
Intended status: Standards Track Facebook Intended status: Standards Track
Expires: January 16, 2013 July 15, 2012 Expires: February 1, 2013
The OAuth 2.0 Authorization Framework The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-30 draft-ietf-oauth-v2-31
Abstract Abstract
The OAuth 2.0 authorization framework enables a third-party The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849. in RFC 5849.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2013. This Internet-Draft will expire on February 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 31 skipping to change at page 4, line 31
A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 68 A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 68
A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 68 A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 68
A.15. "username" Syntax . . . . . . . . . . . . . . . . . . . . 68 A.15. "username" Syntax . . . . . . . . . . . . . . . . . . . . 68
A.16. "password" Syntax . . . . . . . . . . . . . . . . . . . . 69 A.16. "password" Syntax . . . . . . . . . . . . . . . . . . . . 69
A.17. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 69 A.17. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 69
A.18. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 69 A.18. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 69
Appendix B. Use of application/x-www-form-urlencoded Media Appendix B. Use of application/x-www-form-urlencoded Media
Type . . . . . . . . . . . . . . . . . . . . . . . . 69 Type . . . . . . . . . . . . . . . . . . . . . . . . 69
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 70 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 70
Appendix D. Document History . . . . . . . . . . . . . . . . . . 71 Appendix D. Document History . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 72
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
requests an access restricted resource (protected resource) on the requests an access restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with restricted resources, the resource owner shares its credentials with
the third-party. This creates several problems and limitations: the third-party. This creates several problems and limitations:
skipping to change at page 22, line 10 skipping to change at page 22, line 10
changing its credentials, thus preventing an attacker from abusing changing its credentials, thus preventing an attacker from abusing
stolen refresh tokens. Changing a single set of client stolen refresh tokens. Changing a single set of client
credentials is significantly faster than revoking an entire set of credentials is significantly faster than revoking an entire set of
refresh tokens. refresh tokens.
o Implementing authentication management best practices, which o Implementing authentication management best practices, which
require periodic credential rotation. Rotation of an entire set require periodic credential rotation. Rotation of an entire set
of refresh tokens can be challenging, while rotation of a single of refresh tokens can be challenging, while rotation of a single
set of client credentials is significantly easier. set of client credentials is significantly easier.
A public client that was not issued a client password MUST use the A client MAY use the "client_id" request parameter to identify itself
"client_id" request parameter to identify itself when sending when sending requests to the token endpoint. In the
requests to the token endpoint. This allows the authorization server "authorization_code" "grant_type" request to the token endpoint, an
to ensure that the code was issued to the same client. Sending unauthenticated client MUST send its "client_id" to prevent itself
"client_id" prevents the client from inadvertently accepting a code from inadvertently accepting a code intended for a client with a
intended for a client with a different "client_id". This protects different "client_id". This protects the client from substitution of
the client from substitution of the authentication code. (It the authentication code. (It provides no additional security for the
provides no additional security for the protected resource.) protected resource.)
3.3. Access Token Scope 3.3. Access Token Scope
The authorization and token endpoints allow the client to specify the The authorization and token endpoints allow the client to specify the
scope of the access request using the "scope" request parameter. In scope of the access request using the "scope" request parameter. In
turn, the authorization server uses the "scope" response parameter to turn, the authorization server uses the "scope" response parameter to
inform the client of the scope of the access token issued. inform the client of the scope of the access token issued.
The value of the scope parameter is expressed as a list of space- The value of the scope parameter is expressed as a list of space-
delimited, case sensitive strings. The strings are defined by the delimited, case sensitive strings. The strings are defined by the
skipping to change at page 28, line 14 skipping to change at page 28, line 14
grant_type grant_type
REQUIRED. Value MUST be set to "authorization_code". REQUIRED. Value MUST be set to "authorization_code".
code code
REQUIRED. The authorization code received from the REQUIRED. The authorization code received from the
authorization server. authorization server.
redirect_uri redirect_uri
REQUIRED, if the "redirect_uri" parameter was included in the REQUIRED, if the "redirect_uri" parameter was included in the
authorization request as described in Section 4.1.1, and their authorization request as described in Section 4.1.1, and their
values MUST be identical. values MUST be identical.
client_id
REQUIRED, if the client is not authenticating with the
authorization server as described in Section 3.2.1.
If the client type is confidential or the client was issued client If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described client MUST authenticate with the authorization server as described
in Section 3.2.1. in Section 3.2.1.
For example, the client makes the following HTTP request using TLS For example, the client makes the following HTTP request using TLS
(with extra line breaks for display purposes only): (with extra line breaks for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
skipping to change at page 28, line 38 skipping to change at page 28, line 41
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
The authorization server MUST: The authorization server MUST:
o require client authentication for confidential clients or for any o require client authentication for confidential clients or for any
client that was issued client credentials (or with other client that was issued client credentials (or with other
authentication requirements), authentication requirements),
o authenticate the client if client authentication is included, o authenticate the client if client authentication is included,
o ensure the authorization code was issued to the authenticated o ensure the authorization code was issued to the authenticated
confidential client or to the public client identified by the confidential client, or if the client is public, ensure the code
"client_id" in the request, was issued to "client_id" in the request,
o verify that the authorization code is valid, and o verify that the authorization code is valid, and
o ensure that the "redirect_uri" parameter is present if the o ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization "redirect_uri" parameter was included in the initial authorization
request as described in Section 4.1.1, and if included ensure request as described in Section 4.1.1, and if included ensure
their values are identical. their values are identical.
4.1.4. Access Token Response 4.1.4. Access Token Response
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh authorization server issues an access token and optional refresh
skipping to change at page 65, line 17 skipping to change at page 65, line 17
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E., Sperberg-McQueen, C., Yergeau, F., Paoli, J., Bray, T.,
and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
12.2. Informative References 12.2. Informative References
[I-D.draft-hardt-oauth-01] [I-D.draft-hardt-oauth-01]
Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth
Web Resource Authorization Profiles", January 2010. Web Resource Authorization Profiles", January 2010.
skipping to change at page 71, line 15 skipping to change at page 71, line 15
This document was produced under the chairmanship of Blaine Cook, This document was produced under the chairmanship of Blaine Cook,
Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins. Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins.
The area directors included Lisa Dusseault, Peter Saint-Andre, and The area directors included Lisa Dusseault, Peter Saint-Andre, and
Stephen Farrell. Stephen Farrell.
Appendix D. Document History Appendix D. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-31
o Clarify that any client can send "client_id" but that sending it
is only required when using the code flow if the client is not
otherwise authenticated.
o Removed David Recordon's name from the author list, at his
request.
-30 -30
o Added text explaining why the "server_error" and o Added text explaining why the "server_error" and
"temporarily_unavailable" error codes are needed. "temporarily_unavailable" error codes are needed.
-29 -29
o Added "MUST" to "A public client that was not issued a client o Added "MUST" to "A public client that was not issued a client
password MUST use the "client_id" request parameter to identify password MUST use the "client_id" request parameter to identify
itself when sending requests to the token endpoint" and added text itself when sending requests to the token endpoint" and added text
explaining why this must be so. explaining why this must be so.
o Added that the authorization server MUST "ensure the authorization o Added that the authorization server MUST "ensure the authorization
skipping to change at page 72, line 24 skipping to change at page 72, line 29
as the password for HTTP Basic. as the password for HTTP Basic.
-27 -27
o Added character set restrictions for error, error_description, and o Added character set restrictions for error, error_description, and
error_uri parameters consistent with the OAuth Bearer spec. error_uri parameters consistent with the OAuth Bearer spec.
o Added "resource access error response" as an error usage location o Added "resource access error response" as an error usage location
in the OAuth Extensions Error Registry. in the OAuth Extensions Error Registry.
o Added an ABNF for all message elements. o Added an ABNF for all message elements.
o Corrected editorial issues identified during review. o Corrected editorial issues identified during review.
Authors' Addresses Author's Address
Dick Hardt (editor) Dick Hardt (editor)
Microsoft Microsoft
Email: dick.hardt@gmail.com Email: dick.hardt@gmail.com
URI: http://dickhardt.org/ URI: http://dickhardt.org/
David Recordon
Facebook
Email: dr@fb.com
URI: http://www.davidrecordon.com/
 End of changes. 11 change blocks. 
19 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/