Internet DRAFT - draft-park-oauth-revoke
draft-park-oauth-revoke
OAUTH Working Group PARK
Internet Draft PARK
Intended status: <Informational> JUNG
Expires: December 2015 Soongsil University
June 30, 2015
The OAuth 2.0 Risk notification and Token Revocation from Resource
Server
draft-park-oauth-revoke-00.txt
Abstract
This document proposes the revocation of an access token in the case
that a client uses the access token illegally or maliciously.
Contrast to the existing revocation defined in RFC7009, the proposed
revocation is initiated by a resource server when the abnormal
behaviors of a client such as too many DB queries are detected. The
revocation process after revocation initiation is based on RFC7009.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 30, 2015..
PARK Expires December 30, 2015 [Page 1]
Internet-Draft OAuth 2.0 Risk notify and Revocation June 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Risk Notification .......................................... 3
3.1. Overview ............................................... 3
3.2. Risk Notification....................................... 4
3.2.1 The "token_risk_type" value ...................... 5
3.3. Risk Notification Acknowledgement ...................... 5
4. Security Considerations...................................... 5
5. IANA Considerations ......................................... 5
6. Conclusion .................................................. 6
7. References .................................................. 6
8. Acknowledgement ............................................. 6
1. Introduction
Token Revocation [RFC7009] describes the revocation for refresh and
access tokens specified in the OAuth 2.0 core specifications
[RFC6749]. If a resource owner wants to revoke access given to a
client in some cases: logout, identity change, or application
uninstall, the client can request the token revocation to an
authorization server. On receiving the request, the authorization
server cleans up data associated with that token and the underlying
authorization grant.
This draft supplements the Token Revocation with an additional
revocation triggered by a resource server. This draft considers the
case that a client accesses to resources legally with a malicious
purpose, or tries to access unauthorized resources illegally. In
most cases, a resource owner cannot know the client's behaviors
PARK Expires December 30, 2015 [Page 2]
Internet-Draft OAuth 2.0 Risk notify and Revocation June 2015
after the access token is issued. Therefore, when the resource
server detects abnormal behaviors of the client, it should send the
risk notification including the risk type to the resource owner.
According to the resource owner's judgment, either the revocation
process defined in [RFC7009] may be followed or the risk
notification may be discarded.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Resource Owner (RO)
Resource Server (RS)
Authentication Server (AS)
3. Risk Notification
3.1. Overview
If any abnormal behavior is detected in Resource Server (RS), RS
sends Risk Notification to Resource Owner (RO), which enables RO to
judge whether or not the issued access token should be revoked due
to the reported behavior. Receiving Risk Notification, RO either may
request the revocation of the access token to a client or may
discard the Risk Notification. If the client receives the revocation
request from RO, it revokes the access token in the way of [RFC7009].
The details are as follows.
+------+ +----------+ +------+ +------+
| AS | | client | | RO | | RS |
+------+ +----------+ +------+ +------+
|<---------------|
Risk Notification
|<-----------------|
PARK Expires December 30, 2015 [Page 3]
Internet-Draft OAuth 2.0 Risk notify and Revocation June 2015
Token Revocation Request
|<------------------|
Token Revocation Request
|------------------>|
Token Revocation Response
Figure 1. Risk Notification and Revocation Flow
+------+ +------+
| RO | | RS |
+------+ +------+
|<--------------------------|
Risk Notification
|-------------------------->|
Risk Notification Acknowledgment
Figure 2. Risk Notification Acknowledgment
3.2. Risk Notification
Risk Notification informs RO of the client's abnormal behaviors, and
has the following format:
Token REQUIRED. Decide whenever when token revocation is performed.
token_risk_type REQUIRED. Type of risks in the server resource are
specified and the content explanation are sent.
PARK Expires December 30, 2015 [Page 4]
Internet-Draft OAuth 2.0 Risk notify and Revocation June 2015
3.2.1. The "token_risk_type" value
Risk Type: too_many_quarries, too_many_download,
unauthorized_access, etc.
3.3. Risk Notification Acknowledgement
If RO decides not to revoke the access token, it sends Risk
Notification Acknowledgement to RS in order to inform that the
access token can be kept valid.
token REQUIRED. The token that the resource owner does not wants to
get revoked.
4. Security Considerations
A client can access the privileged resources with the access token,
which is the legal behavior. However, a malicious client might
exploit the legal behavior to attack RS, e.g., a number of quarries
to Database, or try to access unauthorized resources illegally.
Although [RFC6819] mentioned about a malicious client, it does not
consider these behaviors stated in this draft. Therefore, this
proposed revocation can prevent those abnormal behaviors, and make
up for this security vulnerability.
5. IANA Considerations
<TBD>
6. Conclusions
Various attacks of OAuth 2.0 protocol are defined in [RFC6819].
However, if RS notices the legal but malicious behaviors or the
illegal behaviors other than those specified in Access Token, and
alerts RO to such treats, the use of access token can be verified
through the judgment of RO, and furthermore, potential threats from
malicious clients can be prevented.
PARK Expires December 30, 2015 [Page 5]
Internet-Draft OAuth 2.0 Risk notify and Revocation June 2015
7. References
[1] [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth
2.0 Threat Model and Security Considerations", RFC
6819, January 2013.
[2] [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
[3] [RFC7009] Lodderstedt, T., Dronia, S., Scurtescu M., "OAuth
2.0 Token Revocation", RFC 7009, August 2013.
8. Acknowledgments
<TBD>
PARK Expires December 30, 2015 [Page 6]
Internet-Draft OAuth 2.0 Risk notify and Revocation June 2015
Authors' Addresses
Jungsoo Park
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email : ddukki86@ssu.ac.kr
Minho Park
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email : mhp@ssu.ac.kr
Souhwan Jung
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: souhwanj@ssu.ac.kr
PARK Expires December 30, 2015 [Page 7]
