idnits 2.17.1 draft-ietf-oauth-revocation-00.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 (May 26, 2012) is 4343 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) == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-26 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authentication Protocol T. Lodderstedt, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track S. Dronia 5 Expires: November 27, 2012 6 M. Scurtescu 7 Google 8 May 26, 2012 10 Token Revocation 11 draft-ietf-oauth-revocation-00 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 November 27, 2012. 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. JSONP Support . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 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 and facilitates the following use cases: 76 o The end-user triggers revocation from within the client that sends 77 the appropriate revocation request to the autorization server. 78 From the end-user's perspective, this looks like a "logout" or 79 "reset" function. The request causes the removal of the client 80 permissions associated with the particular token to access the 81 end-user's protected resources. This use case makes it even more 82 comfortable to the end-user to revoke his access grant immediately 83 via the client. 85 o In contrast to revocation by a client, the authorization server 86 (or a related entity) may offer its end-users a self-care portal 87 to delete access grants given to clients independent of any token 88 storing devices. Such a portal offers the possibility to an end- 89 user to look at and revoke all access grants he once authorized. 90 In cases the token storing device is not available, e.g. it is 91 lost or stolen, revocation by a self-care portal is the only 92 possibility to limit or avoid abuse. 94 In the end, security, usability, and ease of use are increased by 95 token revocation. 97 By using an additional endpoint, the token revocation endpoint, 98 clients can request the revocation of a particular token. Compliant 99 implementation MUST support the revocation of refresh tokens, access 100 token revocation MAY be supported. 102 2. Token Revocation 104 The client requests the revocation of a particular token by making an 105 HTTP POST request to the token revocation endpoint. The location of 106 the token revocation endpoint can be found in the authorization 107 servers documentation. The token endpoint URI MAY include a query 108 component. 110 Since requests to the token revocation endpoint result in the 111 transmission of plain text credentials in the HTTP request, the 112 authorization server MUST require the use of a transport-layer 113 security mechanism when sending requests to the token revocation 114 endpoints. The authorization server MUST support TLS 1.0 115 ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future 116 replacements, and MAY support additional transport-layer mechanisms 117 meeting its security requirements. 119 The client constructs the request by including the following 120 parameters using the "application/x-www-form-urlencoded" format in 121 the HTTP request entity-body: 123 token REQUIRED. The token that the client wants to get revoked. 124 Note: the authorization server is supposed to detect the 125 token type automatically. 127 The client also includes its authentication credentials as described 128 in Section 2.3. of [I-D.ietf-oauth-v2]. 130 For example, a client may request the revocation of a refresh token 131 with the following request (line breaks are for display purposes 132 only): 134 POST /revoke HTTP/1.1 135 Host: server.example.com 136 Content-Type: application/x-www-form-urlencoded 137 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 139 token=45ghiukldjahdnhzdauz& 141 The authorization server first validates the client credentials (if 142 present) and verifies whether the client is authorized to revoke the 143 particular token based on the client identity and its policy. For 144 example, only the client the token has been issued for might be 145 allowed to revoke it. It is also conceivable to allow a dedicated 146 user self-care portal to revoke all kinds of tokens. 148 In the next step, the authorization server invalidates the token. 149 Whether the revocation takes effect instantly or with some delay 150 depends on the architecture of the particular deployment. The client 151 MUST NOT make any assumptions about the timing and MUST NOT use the 152 token again. 154 If the processed token is a refresh token and the authorization 155 server supports the revocation of access tokens, then the 156 authorization server SHOULD also invalidate all access tokens issued 157 for that refresh token. 159 The authorization server indicates a successful processing of the 160 request by a HTTP status code 200. Status code 401 indicates a 161 failed client authentication, whereas a status code 403 is used if 162 the client is not authorized to revoke the particular token. For all 163 other error conditions, a status code 400 is used along with an error 164 response as defined in section 5.2. of [I-D.ietf-oauth-v2]. The 165 following error codes are defined for the token revocation endpoint: 167 unsupported_token_type The authorization server does not support the 168 revocation of the presented token type. I.e. the client 169 tried to revoke an access token on a server not supporting 170 this feature. 172 invalid_token The presented token is invalid. 174 2.1. JSONP Support 176 The revocation endpoint MAY support JSONP [jsonp] by allowing GET 177 requests with an additional parameter: 179 callback The qualified name of a JavaScript function. 181 Example request: 183 https://example.com/revoke?token=45ghiukldjahdnhzdauz& 184 callback=package.myCallback 186 Successful response: 188 package.myCallback(); 190 Error response: 192 package.myCallback({"error":"invalid_token"}); 194 3. Acknowledgements 196 We would like to thank Sebastian Ebling, Christian Stuebner, Brian 197 Campbell, Igor Faynberg, Lukas Rosenstock, and Justin P. Richer for 198 their valuable feedback. 200 4. IANA Considerations 202 This draft includes no request to IANA. 204 5. Security Considerations 206 All relevant security considerations have been given in the 207 functional specification. 209 6. References 211 6.1. Normative References 213 [I-D.ietf-oauth-v2] 214 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 215 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 216 in progress), May 2012. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 222 RFC 2246, January 1999. 224 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 225 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 227 6.2. Informative References 229 [jsonp] Ippolito, B., "Remote JSON - JSONP", December 2005. 231 Authors' Addresses 233 Torsten Lodderstedt (editor) 234 Deutsche Telekom AG 236 Email: torsten@lodderstedt.net 238 Stefanie Dronia 240 Email: sdronia@gmx.de 242 Marius Scurtescu 243 Google 245 Email: mscurtescu@google.com