| < 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 71, line 44 ¶ | skipping to change at page 72, line 4 ¶ | |||
| Type: application/x-www-form-urlencoded;charset=UTF-8". | Type: application/x-www-form-urlencoded;charset=UTF-8". | |||
| o Added the phrase "with a character encoding of UTF-8" when | o Added the phrase "with a character encoding of UTF-8" when | |||
| describing how to send requests using the HTTP request entity- | describing how to send requests using the HTTP request entity- | |||
| body. | body. | |||
| o For symmetry when using HTTP Basic authentication, also apply the | o For symmetry when using HTTP Basic authentication, also apply the | |||
| "application/x-www-form-urlencoded" encoding to the client | "application/x-www-form-urlencoded" encoding to the client | |||
| password, just as was already done for the client identifier. | password, just as was already done for the client identifier. | |||
| o Added "The ABNF below is defined in terms of Unicode code points | o Added "The ABNF below is defined in terms of Unicode code points | |||
| [W3C.REC-xml-20081126]; these characters are typically encoded in | [W3C.REC-xml-20081126]; these characters are typically encoded in | |||
| UTF-8". | UTF-8". | |||
| o Replaced UNICODENOCTRLCHAR in ABNF with UNICODECHARNOCRLF = %x09 / | o Replaced UNICODENOCTRLCHAR in ABNF with UNICODECHARNOCRLF = %x09 / | |||
| %x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF. | %x20-7E / %x80-D7FF / %xE000-FFFD / %x10000-10FFFF. | |||
| o Corrected incorrect uses of "which". | o Corrected incorrect uses of "which". | |||
| o Reduced multiple blank lines around artwork elements to single | o Reduced multiple blank lines around artwork elements to single | |||
| blank lines. | blank lines. | |||
| o Removed Eran Hammer's name from the author list, at his request. | o Removed Eran Hammer's name from the author list, at his request. | |||
| Dick Hardt is now listed as the editor. | Dick Hardt is now listed as the editor. | |||
| -28 | -28 | |||
| o Updated the ABNF in the manner discussed by the working group, | o Updated the ABNF in the manner discussed by the working group, | |||
| allowing "username" and "password" to be Unicode and restricting | allowing "username" and "password" to be Unicode and restricting | |||
| "client_id" and "client_secret" to ASCII. | "client_id" and "client_secret" to ASCII. | |||
| o Specified the use of the application/x-www-form-urlencoded | o Specified the use of the application/x-www-form-urlencoded | |||
| content-type encoding method to encode the "client_id" when used | content-type encoding method to encode the "client_id" when used | |||
| 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 | ||||
| Email: dr@fb.com | ||||
| URI: http://www.davidrecordon.com/ | ||||
| End of changes. 13 change blocks. | ||||
| 20 lines changed or deleted | 30 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||