OAUTH Working Group PARK Internet Draft PARK Intended status: 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 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 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]