< draft-ietf-oauth-v2-bearer-16.txt   draft-ietf-oauth-v2-bearer-17.txt >
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track D. Hardt Intended status: Standards Track D. Hardt
Expires: August 2, 2012 independent Expires: August 19, 2012 independent
D. Recordon D. Recordon
Facebook Facebook
January 30, 2012 February 16, 2012
The OAuth 2.0 Authorization Protocol: Bearer Tokens The OAuth 2.0 Authorization Protocol: Bearer Tokens
draft-ietf-oauth-v2-bearer-16 draft-ietf-oauth-v2-bearer-17
Abstract Abstract
This specification describes how to use bearer tokens in HTTP This specification describes how to use bearer tokens in HTTP
requests to access OAuth 2.0 protected resources. Any party in requests to access OAuth 2.0 protected resources. Any party in
possession of a bearer token (a "bearer") can use it to get access to possession of a bearer token (a "bearer") can use it to get access to
the associated resources (without demonstrating possession of a the associated resources (without demonstrating possession of a
cryptographic key). To prevent misuse, bearer tokens need to be cryptographic key). To prevent misuse, bearer tokens need to be
protected from disclosure in storage and in transport. protected from disclosure in storage and in transport.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 August 2, 2012. This Internet-Draft will expire on August 19, 2012.
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 11, line 40 skipping to change at page 11, line 40
communication interaction between the client and the authorization communication interaction between the client and the authorization
server, as well as the interaction between the client and the server, as well as the interaction between the client and the
resource server, utilize confidentiality and integrity protection. resource server, utilize confidentiality and integrity protection.
Since TLS is mandatory to implement and to use with this Since TLS is mandatory to implement and to use with this
specification, it is the preferred approach for preventing token specification, it is the preferred approach for preventing token
disclosure via the communication channel. For those cases where the disclosure via the communication channel. For those cases where the
client is prevented from observing the contents of the token, token client is prevented from observing the contents of the token, token
encryption MUST be applied in addition to the usage of TLS encryption MUST be applied in addition to the usage of TLS
protection. As a further defense against token disclosure, the protection. As a further defense against token disclosure, the
client MUST validate the TLS certificate chain when making requests client MUST validate the TLS certificate chain when making requests
to protected resources. to protected resources, including checking the Certificate Revocation
List (CRL) [RFC5280].
Cookies are typically transmitted in the clear. Thus, any Cookies are typically transmitted in the clear. Thus, any
information contained in them is at risk of disclosure. Therefore, information contained in them is at risk of disclosure. Therefore,
bearer tokens MUST NOT be stored in cookies that can be sent in the bearer tokens MUST NOT be stored in cookies that can be sent in the
clear. clear.
In some deployments, including those utilizing load balancers, the In some deployments, including those utilizing load balancers, the
TLS connection to the resource server terminates prior to the actual TLS connection to the resource server terminates prior to the actual
server that provides the resource. This could leave the token server that provides the resource. This could leave the token
unprotected between the front end server where the TLS connection unprotected between the front end server where the TLS connection
skipping to change at page 12, line 20 skipping to change at page 12, line 21
of achieving this is by putting a validity time field inside the of achieving this is by putting a validity time field inside the
protected part of the token. Note that using short-lived (one hour protected part of the token. Note that using short-lived (one hour
or less) tokens reduces the impact of them being leaked. Second, or less) tokens reduces the impact of them being leaked. Second,
confidentiality protection of the exchanges between the client and confidentiality protection of the exchanges between the client and
the authorization server and between the client and the resource the authorization server and between the client and the resource
server MUST be applied. As a consequence, no eavesdropper along the server MUST be applied. As a consequence, no eavesdropper along the
communication path is able to observe the token exchange. communication path is able to observe the token exchange.
Consequently, such an on-path adversary cannot replay the token. Consequently, such an on-path adversary cannot replay the token.
Furthermore, when presenting the token to a resource server, the Furthermore, when presenting the token to a resource server, the
client MUST verify the identity of that resource server, as per client MUST verify the identity of that resource server, as per
Representation and Verification of Domain-Based Application Service Section 3.1 of HTTP Over TLS [RFC2818]. Note that the client MUST
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) validate the TLS certificate chain when making these requests to
Certificates in the Context of Transport Layer Security (TLS) protected resources. Presenting the token to an unauthenticated and
[RFC6125]. Note that the client MUST validate the TLS certificate unauthorized resource server or failing to validate the certificate
chain when making these requests to protected resources. Presenting chain will allow adversaries to steal the token and gain unauthorized
the token to an unauthenticated and unauthorized resource server or access to protected resources.
failing to validate the certificate chain will allow adversaries to
steal the token and gain unauthorized access to protected resources.
4.3. Summary of Recommendations 4.3. Summary of Recommendations
Safeguard bearer tokens: Client implementations MUST ensure that Safeguard bearer tokens: Client implementations MUST ensure that
bearer tokens are not leaked to unintended parties, as they will bearer tokens are not leaked to unintended parties, as they will
be able to use them to gain access to protected resources. This be able to use them to gain access to protected resources. This
is the primary security consideration when using bearer tokens and is the primary security consideration when using bearer tokens and
underlies all the more specific recommendations that follow. underlies all the more specific recommendations that follow.
Validate SSL certificate chains: The client MUST validate the TLS Validate SSL certificate chains: The client MUST validate the TLS
skipping to change at page 14, line 51 skipping to change at page 14, line 51
Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0
Authorization Protocol", draft-ietf-oauth-v2-23 (work in Authorization Protocol", draft-ietf-oauth-v2-23 (work in
progress), January 2012. progress), January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Verification of Domain-Based Application Service Identity Housley, R., and W. Polk, "Internet X.509 Public Key
within Internet Public Key Infrastructure Using X.509 Infrastructure Certificate and Certificate Revocation List
(PKIX) Certificates in the Context of Transport Layer (CRL) Profile", RFC 5280, May 2008.
Security (TLS)", RFC 6125, March 2011.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
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>.
skipping to change at page 16, line 13 skipping to change at page 16, line 13
Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and
concepts within are a product of the OAuth community, the WRAP concepts within are a product of the OAuth community, the WRAP
community, and the OAuth Working Group. community, and the OAuth Working Group.
The OAuth Working Group has dozens of very active contributors who The OAuth Working Group has dozens of very active contributors who
proposed ideas and wording for this document, including: Michael proposed ideas and wording for this document, including: Michael
Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, John Bradley, Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, John Bradley,
Brian Campbell, Leah Culver, Bill de hOra, Brian Ellin, Igor Brian Campbell, Leah Culver, Bill de hOra, Brian Ellin, Igor
Faynberg, Stephen Farrell, George Fletcher, Tim Freeman, Evan Faynberg, Stephen Farrell, George Fletcher, Tim Freeman, Evan
Gilbert, Yaron Y. Goland, Thomas Hardjono, Justin Hart, Phil Hunt, Gilbert, Yaron Y. Goland, Thomas Hardjono, Justin Hart, Phil Hunt,
John Kemp, Eran Hammer-Lahav, Chasen Le Hara, Barry Leiba, Michael B. John Kemp, Eran Hammer, Chasen Le Hara, Barry Leiba, Michael B.
Jones, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao, Jones, Torsten Lodderstedt, Eve Maler, James Manger, Laurence Miao,
William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, William J. Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke,
Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius
Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian
Stuebner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane Stuebner, Paul Tarjan, Hannes Tschofenig, Franklin Tse, and Shane
Weeden. Weeden.
Appendix B. Document History Appendix B. 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 ]]
-17
o Restore RFC 2818 reference for server identity verification and
add RFC 5280 reference for certificate revocation lists, per Gen-
ART review comments.
-16 -16
o Use the HTTPbis auth-param syntax for Bearer challenge attributes. o Use the HTTPbis auth-param syntax for Bearer challenge attributes.
o Dropped the sentence "The "realm" value is intended for o Dropped the sentence "The "realm" value is intended for
programmatic use and is not meant to be displayed to end users". programmatic use and is not meant to be displayed to end users".
o Reordered form-encoded body parameter description bullets for o Reordered form-encoded body parameter description bullets for
better readability. better readability.
 End of changes. 10 change blocks. 
19 lines changed or deleted 25 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/