idnits 2.17.1 draft-ietf-oauth-revocation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2012) is 4218 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group T. Lodderstedt, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track S. Dronia 5 Expires: April 9, 2013 6 M. Scurtescu 7 Google 8 October 6, 2012 10 Token Revocation 11 draft-ietf-oauth-revocation-01 13 Abstract 15 This draft proposes an additional endpoint for OAuth authorization 16 servers for revoking tokens. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 9, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Token Revocation . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Cross-Origin Support . . . . . . . . . . . . . . . . . . . 5 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The OAuth 2.0 core specification [I-D.ietf-oauth-v2] defines several 72 ways for a client to obtain refresh and access tokens. This 73 specification supplements the core specification with a mechanism to 74 revoke both types of tokens. A token is the external representation 75 of an access grant issued by a resource owner to a particular client. 76 A revocation request may discard the actual token as well as other 77 tokens based on the same access grant and the access grant itself. 79 This mechanism facilitates the following use cases: 81 o The end-user triggers revocation from within the client that sends 82 the appropriate revocation request to the autorization server. 83 The request causes the removal of the client's access grant the 84 particular token refers to. From the end-user's perspective, this 85 looks like a "logout" or "reset" function. This use case makes it 86 even more comfortable to the end-user to revoke his access grant 87 immediately via the client. 89 o In contrast to revocation by a client, the authorization server 90 (or a related entity) may offer its end-users a self-care portal 91 to delete access grants given to clients independent of any token 92 storing devices. Such a portal offers the possibility to an end- 93 user to look at and revoke all access grants he once authorized. 94 In cases the token storing device is not available, e.g. it is 95 lost or stolen, revocation by a self-care portal is the only 96 possibility to limit or avoid abuse. 98 In the end, security, usability, and ease of use are increased by 99 token revocation. 101 By using an additional endpoint, the token revocation endpoint, 102 clients can request the revocation of a particular token. Compliant 103 implementation MUST support the revocation of refresh tokens, access 104 token revocation MAY be supported. 106 2. Token Revocation 108 The client requests the revocation of a particular token by making an 109 HTTP POST request to the token revocation endpoint. The location of 110 the token revocation endpoint can be found in the authorization 111 server's documentation. The token endpoint URI MAY include a query 112 component. 114 Since requests to the token revocation endpoint result in the 115 transmission of plain text credentials in the HTTP request, the 116 authorization server MUST require the use of a transport-layer 117 security mechanism when sending requests to the token revocation 118 endpoints. The authorization server MUST support TLS 1.0 119 ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future 120 replacements, and MAY support additional transport-layer mechanisms 121 meeting its security requirements. 123 The client constructs the request by including the following 124 parameters using the "application/x-www-form-urlencoded" format in 125 the HTTP request entity-body: 127 token REQUIRED. The token that the client wants to get revoked. 128 Note: the authorization server is supposed to detect the 129 token type automatically. 131 The client also includes its authentication credentials as described 132 in Section 2.3. of [I-D.ietf-oauth-v2]. 134 For example, a client may request the revocation of a refresh token 135 with the following request (line breaks are for display purposes 136 only): 138 POST /revoke HTTP/1.1 139 Host: server.example.com 140 Content-Type: application/x-www-form-urlencoded 141 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 143 token=45ghiukldjahdnhzdauz& 145 The authorization server first validates the client credentials (in 146 case of a confidential client) and verifies whether the client is 147 authorized to revoke the particular token based on the client 148 identity and its policy. For example, only the client the token has 149 been issued for might be allowed to revoke it. It is also 150 conceivable to allow a dedicated user self-care portal to revoke all 151 kinds of tokens. 153 In the next step, the authorization server invalidates the token and 154 the respective access grant. If the particular token is a refresh 155 token and the authorization server supports the revocation of access 156 tokens, then the authorization server SHOULD also invalidate all 157 access tokens based on the same access grant. 159 Whether the revocation takes effect instantly or with some delay 160 depends on the architecture of the particular deployment. The client 161 MUST NOT make any assumptions about the timing and MUST NOT use the 162 token again. 164 The authorization server indicates a successful processing of the 165 request by a HTTP status code 200. Status code 401 indicates a 166 failed client authentication, whereas a status code 403 is used if 167 the client is not authorized to revoke the particular token. For all 168 other error conditions, a status code 400 is used along with an error 169 response as defined in section 5.2. of [I-D.ietf-oauth-v2]. The 170 following error codes are defined for the token revocation endpoint: 172 unsupported_token_type The authorization server does not support the 173 revocation of the presented token type. I.e. the client 174 tried to revoke an access token on a server not supporting 175 this feature. 177 invalid_token The presented token is invalid. 179 2.1. Cross-Origin Support 181 The revokation end-point SHOULD support CORS [W3C.WD-cors-20120403] 182 if it is aimed at use in combination with user-agent-based 183 applications. In addition, for interoperability with legacy user- 184 agents, it MAY offer JSONP [jsonp] by allowing GET requests with an 185 additional parameter: 187 callback The qualified name of a JavaScript function. 189 Example request: 191 https://example.com/revoke?token=45ghiukldjahdnhzdauz& 192 callback=package.myCallback 194 Successful response: 196 package.myCallback(); 198 Error response: 200 package.myCallback({"error":"invalid_token"}); 202 Clients should be aware that when relying on JSONP, a malicious 203 revokation end-point may attempt to inject malicious code into the 204 client. 206 3. Acknowledgements 208 We would like to thank Michiel de Jong, Doug Foiles, Paul Madsen, 209 George Fletcher, Sebastian Ebling, Christian Stuebner, Brian 210 Campbell, Igor Faynberg, Lukas Rosenstock, and Justin P. Richer for 211 their valuable feedback. 213 4. IANA Considerations 215 This draft includes no request to IANA. 217 5. Security Considerations 219 All relevant security considerations have been given in the 220 functional specification. 222 6. References 224 6.1. Normative References 226 [I-D.ietf-oauth-v2] 227 Hardt, D., "The OAuth 2.0 Authorization Framework", 228 draft-ietf-oauth-v2-31 (work in progress), August 2012. 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 234 RFC 2246, January 1999. 236 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 237 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 239 6.2. Informative References 241 [W3C.WD-cors-20120403] 242 Kesteren, A., "Cross-Origin Resource Sharing", World Wide 243 Web Consortium LastCall WD-cors-20120403, April 2012, 244 . 246 [jsonp] Ippolito, B., "Remote JSON - JSONP", December 2005. 248 Authors' Addresses 250 Torsten Lodderstedt (editor) 251 Deutsche Telekom AG 253 Email: torsten@lodderstedt.net 254 Stefanie Dronia 256 Email: sdronia@gmx.de 258 Marius Scurtescu 259 Google 261 Email: mscurtescu@google.com