One document matched: draft-lodderstedt-oauth-revocation-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
		This template is for creating an Internet Draft using xml2rfc, which
		is available here: http://xml.resource.org.
	-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
	<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
	<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!--
		For a complete list and description of processing instructions (PIs),
		please see http://xml.resource.org/authoring/README.html.
	-->
<!--
		Below are generally applicable Processing Instructions (PIs) that most
		I-Ds might want to use. (Here they are set differently than their
		defaults in xml2rfc v1.32)
	-->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!--
		control vertical white space (using these PIs as follows is
		recommended by the RFC Editor)
	-->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-lodderstedt-oauth-revocation-01" ipr="trust200902">
	<!--
		category values: std, bcp, info, exp, and historic ipr values:
		full3667, noModification3667, noDerivatives3667 you can add the
		attributes updates="NNNN" and obsoletes="NNNN" they will automatically
		be output with "(if approved)"
	-->
	<!-- ***** FRONT MATTER ***** -->
	<front>
		<!--
			The abbreviated title is used in the page header - it is only
			necessary if the full title is longer than 39 characters
		-->
		<title abbrev="Token Revocation">Token Revocation</title>
		<author fullname="Dr.-Ing. Torsten Lodderstedt" initials="T." surname="Lodderstedt" role="editor">
			<organization>Deutsche Telekom AG</organization>
			<address>
				<email>torsten@lodderstedt.net</email>
				<!-- uri and facsimile elements may also be added -->
			</address>
		</author>
		<author fullname="Stefanie Dronia" initials="S." surname="Dronia">
			<organization>SYRACOM Consulting AG</organization>
			<address>
				<email>sdronia@gmx.de</email>
				<!-- uri and facsimile elements may also be added -->
			</address>
		</author>
		<date day="10" month="January" year="2011"/>
		<!-- Meta-data Declarations -->
		<area>Applications Area</area>
		<workgroup>Open Authentication Protocol</workgroup>
		<!--
			WG name at the upperleft corner of the doc, IETF is fine for
			individual submissions. If this element is not present, the default
			is "Network Working Group", which is used by the RFC Editor as a nod
			to the history of the IETF.
		-->
		<keyword>token revocation</keyword>
		<keyword>oauth2</keyword>
		<!--
			Keywords will be incorporated into HTML output files in a meta tag
			but they have no effect on text or nroff output. If you submit your
			draft to the RFC Editor, the keywords will be used for the search
			engine.
		-->
		<abstract>
			<t>This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens.</t>
		</abstract>
	</front>
	<middle>
		<section title="Introduction">
			<t>
			The current OAuth 2.0 draft <xref target="draft-ietf-oauth-v2-11"/> defines several ways for a client to obtain refresh and 
			access tokens. This specification supplements the draft with a mechanism to revoke both types of tokens and facilitates 
			the following use cases.
			<list style="symbols">
					<t> The end-user triggers revocation from within the client that sends the appropriate revocation request to the 
					autorization server. From the end-user's perspective, this looks like a “logout” or “reset” function. The request 
					causes the removal of the client permissions associated with the particular token to access the end-user’s 
					protected resources. This use case makes it even more comfortable to the end-user to revoke his access grant immediately via the client.</t>
					<t>In contrast to revocation by a client, the authorization server (or a related entity) may offer its end-users a 
					self-care portal to delete access grants given to clients independent of any token storing devices. Such a portal 
					offers the possibility to an end-user to look  at and revoke all access grants he once authorized. In cases the token 
					storing device is not available, e.g. it is lost or stolen, revocation by a self-care portal is the only possibility to limit or avoid abuse.</t>
				</list>   			
     			In the end, security, usability, and ease of use are increased by token revocation.
			</t>
			<t>
			By using an additional endpoint, the token revocation endpoint, clients can request the revocation of a particular token. Compliant implementation MUST support the revocation of refresh tokens, access token revocation MAY be supported.
			</t>
		</section>
		<section title="Token Revocation">
			<t>The client requests the revocation of a particular token by 
		making an HTTP "POST" request to the token revocation endpoint.  
		The location of the token revocation endpoint can be found in the authorization
		servers documentation, or can be obtained by using [[OAuth Discovery ]].  
		The token endpoint URI MAY include a query component.</t>
			<t>Since requests to the token revocation endpoint result in the transmission of
   plain text credentials in the HTTP request, the
   authorization server MUST require the use of a transport-layer
   security mechanism when sending requests to the token revocation endpoints.
   Authorization servers MUST support TLS 1.2 as defined in [RFC5246], and MAY support
   additional transport-layer security mechanisms.</t>
			<t>The client authenticates with the authorization server by adding its
   client credentials to the request as described in Section 3 of 
   <xref target="draft-ietf-oauth-v2-11"/>.</t>
			<t>The client constructs the request by including the following
   parameters using the "application/x-www-form-urlencoded" format in
   the HTTP request entity-body:
   
   	<list hangIndent="8" style="hanging">
					<t hangText="token">REQUIRED.  The token that the client wants to get revoked.</t>
					<t hangText="token_type">
							REQUIRED. The type of the token to be revoked, either "refresh_token" or "access_token".
         Information about the supported token types can be found in the 
         authorization server's documentation, or can be obtained by using
         [[OAuth Discovery ]].</t>
				</list>
			</t>
			<t>For example, a client may request the revocation of a refresh token with the following request (line breaks are for display purposes only):
					<figure>
					<artwork><![CDATA[
     POST /revoke HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     token=45ghiukldjahdnhzdauz&token_type=refresh_token&
     client_id=s6BhdRkqt3&client_secret=gX1fBat3bV
				    ]]></artwork>
				</figure>
			</t>
			<t>The authorization server first verifies whether the client is authorized to revoke 
 the particular token based on the client credentials and its policy. For example, only 
 the client the token has been issued for might be allowed to revoke it. It is also
 conceivable to allow a dedicated user self-care portal to revoke all kinds of tokens.</t>
			<t>In the next step, the authorization server invalidates the token. Whether the 
revocation takes effect instantly or with some delay depends on the architecture 
of the particular deployment. The client MUST NOT make any assumptions about the 
timing and MUST NOT use the token again.</t>
			<t>If the processed token is a refresh token and the authorization server supports the revocation
of access tokens, then the authorization server MUST also invalidate all access tokens issued 
for that refresh 
token. </t>
			<t>The authorization server indicates a successful processing of the request by a HTTP status code 204. 
Status code 401 indicates a failed client authentication, whereas a status code 403 is used if the
client is not authorized to revoke the particular token. For all other error conditions, a status 
code 400 is used along with an error response as defined in section 5.3. of <xref target="draft-ietf-oauth-v2-11"/>.
The following error codes are defined for the token revocation endpoint:
   	<list hangIndent="8" style="hanging">
					<t hangText="unsupported_token_type">The authorization server 
						does not support the revocation of the presented token type. I.e. 
						the	client tried to revoke an access token on a server not supporting 
						this feature.</t>
					<t hangText="invalid_token">The presented token is invalid.</t>
				</list>
			</t>
		</section>
		<section anchor="Acknowledgements" title="Acknowledgements">
			<t>We would like to thank Sebastian Ebling and 
			Christian Stübner for their valuable feedback.</t>
		</section>
		<!-- Possibly a 'Contributors' section ... -->
		<section anchor="IANA" title="IANA Considerations">
			<t>This draft includes no request to IANA.</t>
		</section>
		<section anchor="Security" title="Security Considerations">
			<t>All relevant security considerations have been given in the functional specification.</t>
		</section>
	</middle>
	<!--  *****BACK MATTER ***** -->
	<back>
		<references title="Informative References">
			<reference anchor="draft-ietf-oauth-v2-11" target="http://tools.ietf.org/html/draft-ietf-oauth-v2-11">
				<front>
					<title>The OAuth 2.0 Protocol draft-ietf-oauth-v2-11</title>
					<author fullname="Eran Hammer-Lahav" initials="E." role="editor" surname="Hammer-Lahav"/>
					<author fullname="David Recordon" initials="D." surname="Recordon"/>
					<author fullname="Dick Hardt" initials="D." surname="Hardt"/>
					<date day="11" month="December" year="2010"/>
				</front>
			</reference>
		</references>
		<!--  		<references title="Informative References">
		</references>-->
	</back>
</rfc>