draft-ietf-oauth-revocation-10.txt   draft-ietf-oauth-revocation-11.txt 
OAuth Working Group T. Lodderstedt, Ed. OAuth Working Group T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Standards Track S. Dronia Intended status: Standards Track S. Dronia
Expires: December 18, 2013 Expires: January 14, 2014
M. Scurtescu M. Scurtescu
Google Google
June 16, 2013 July 13, 2013
OAuth 2.0 Token Revocation OAuth 2.0 Token Revocation
draft-ietf-oauth-revocation-10 draft-ietf-oauth-revocation-11
Abstract Abstract
This document proposes an additional endpoint for OAuth authorization This document proposes an additional endpoint for OAuth authorization
servers, which allows clients to notify the authorization server that servers, which allows clients to notify the authorization server that
a previously obtained refresh or access token is no longer needed. a previously obtained refresh or access token is no longer needed.
This allows the authorization server to cleanup security credentials. This allows the authorization server to cleanup security credentials.
A revocation request will invalidate the actual token and, if A revocation request will invalidate the actual token and, if
applicable, other tokens based on the same authorization grant. applicable, other tokens based on the same authorization grant.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 18, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Token Revocation . . . . . . . . . . . . . . . . . . . . . . 3 2. Token Revocation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Revocation Request . . . . . . . . . . . . . . . . . . . 3 2.1. Revocation Request . . . . . . . . . . . . . . . . . . . 3
2.2. Revocation Response . . . . . . . . . . . . . . . . . . . 5 2.2. Revocation Response . . . . . . . . . . . . . . . . . . . 5
2.2.1. Error Response . . . . . . . . . . . . . . . . . . . 5 2.2.1. Error Response . . . . . . . . . . . . . . . . . . . 5
2.3. Cross-Origin Support . . . . . . . . . . . . . . . . . . 6 2.3. Cross-Origin Support . . . . . . . . . . . . . . . . . . 6
3. Implementation Note . . . . . . . . . . . . . . . . . . . . . 6 3. Implementation Note . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. OAuth Extensions Error Registration . . . . . . . . . . . 7 4.1. OAuth Extensions Error Registration . . . . . . . . . . . 7
4.1.1. The "unsupported_token_type" Error Value . . . . . . 7 4.1.1. The "unsupported_token_type" Error Value . . . . . . 7
4.1.2. OAuth Token Type Hint Registry . . . . . . . . . . . 7 4.1.2. OAuth Token Type Hint Registry . . . . . . . . . . . 8
4.1.2.1. Registration Template . . . . . . . . . . . . . . 8 4.1.2.1. Registration Template . . . . . . . . . . . . . . 8
4.1.2.2. Initial Registry Contents . . . . . . . . . . . . 8 4.1.2.2. Initial Registry Contents . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The OAuth 2.0 core specification [RFC6749] defines several ways for a The OAuth 2.0 core specification [RFC6749] defines several ways for a
client to obtain refresh and access tokens. This specification client to obtain refresh and access tokens. This specification
supplements the core specification with a mechanism to revoke both supplements the core specification with a mechanism to revoke both
types of tokens. A token is a string representing an authorization types of tokens. A token is a string representing an authorization
grant issued by the resource owner to the client. A revocation grant issued by the resource owner to the client. A revocation
request will invalidate the actual token and, if applicable, other request will invalidate the actual token and, if applicable, other
tokens based on the same authorization grant and the authorization tokens based on the same authorization grant and the authorization
skipping to change at page 3, line 22 skipping to change at page 3, line 22
end-user. end-user.
2. Token Revocation 2. Token Revocation
Implementations MUST support the revocation of refresh tokens and Implementations MUST support the revocation of refresh tokens and
SHOULD support the revocation of access tokens (see Implementation SHOULD support the revocation of access tokens (see Implementation
Note). Note).
The client requests the revocation of a particular token by making an The client requests the revocation of a particular token by making an
HTTP POST request to the token revocation endpoint URL. This URL HTTP POST request to the token revocation endpoint URL. This URL
MUST conform to the rules given in [RFC6749], section 3.1. MUST conform to the rules given in [RFC6749], section 3.1. Clients
MUST verify that the URL is an HTTPS URL.
The means to obtain the location of the revocation endpoint is out of The means to obtain the location of the revocation endpoint is out of
scope of this specification. For example, the client developer may scope of this specification. For example, the client developer may
consult the server's documentation or automatic discovery may be consult the server's documentation or automatic discovery may be
used. As this endpoint is handling security credentials, the used. As this endpoint is handling security credentials, the
endpoint location needs to be obtained from a trustworthy source. endpoint location needs to be obtained from a trustworthy source.
Since requests to the token revocation endpoint result in the Since requests to the token revocation endpoint result in the
transmission of plain text credentials in the HTTP request, the transmission of plain text credentials in the HTTP request, URLs for
authorization server MUST require the use of a transport-layer token revocation endpoints MUST be HTTPS URLs. The authorization
security mechanism when sending requests to the token revocation server MUST use Transport Layer Security (TLS) in a version compliant
endpoints. The authorization server MUST use Transport Layer with [RFC6749], section 1.6. Implementations MAY also support
Security (TLS) in a version compliant with [RFC6749], section 1.6. additional transport-layer security mechanisms that meet their
Implementations MAY also support additional transport-layer security security requirements.
mechanisms that meet their security requirements.
If the host of the token revocation endpoint can also be reached over
HTTP, then the server SHOULD also offer a revocation service at the
corresponding HTTP URI, but MUST NOT publish this URI as a token
revocation endpoint. This ensures that tokens accidentally sent over
HTTP will be revoked.
2.1. Revocation Request 2.1. Revocation Request
The client constructs the request by including the following The client constructs the request by including the following
parameters using the "application/x-www-form-urlencoded" format in parameters using the "application/x-www-form-urlencoded" format in
the HTTP request entity-body: the HTTP request entity-body:
token REQUIRED. The token that the client wants to get revoked. token REQUIRED. The token that the client wants to get revoked.
token_type_hint OPTIONAL. A hint about the type of the token token_type_hint OPTIONAL. A hint about the type of the token
 End of changes. 9 change blocks. 
17 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/