Reference Monitors for Security and Interoperability in OAuth 2.0
OAuth 2.0 is a recent IETF standard devoted to providing authorization to clients requiring access to specific resources over HTTP. It has been pointed out that this framework is potentially subject to security issues, as well as difficulties concerning t
- PDF / 518,328 Bytes
- 15 Pages / 439.37 x 666.142 pts Page_size
- 55 Downloads / 153 Views
Ecole des Mines de Nantes, Nantes, France [email protected] 2 SAP Applied Research, Mougins, France 3 EURECOM, Sophia Antipolis, France
Abstract. OAuth 2.0 is a recent IETF standard devoted to providing authorization to clients requiring access to specific resources over HTTP. It has been pointed out that this framework is potentially subject to security issues, as well as difficulties concerning the interoperability between protocol participants and application evolution. As we show in this paper, there are indeed multiple reasons that make this protocol hard to implement and impede interoperability in the presence of different kinds of client. Our main contribution consists in a framework that harnesses a type-based policy language and aspect-based support for protocol adaptation through flexible reference monitors in order to handle security, interoperability and evolution issues of OAuth 2.0. We apply our framework in the context of three scenarios that make explicit variations in the protocol and show how to handle those issues. Keywords: Aspect oriented programming · Interoperability protocol · Reference monitor · Security · Type system
1
·
OAuth
Introduction
Web services and applications are implemented more and more frequently using open standards for security goals such as WS-policy for SOAP-based services, and, more commonly as part of RESTful APIs, OpenID for authentication as well as OAuth for authorization. OAuth has gained a lot of interest, its 2.0 version recently becoming an IETF standard. All major internet players (Google, Facebook, Microsoft, among others) have already released API’s to allow resource access delegation in web applications using this standard. Although the specifications of the standard are sufficiently clear, developers often have difficulties to correctly implement all of its features. There are This work has been partially supported by the CESSA ANR project (ANR 09-SEGI002-01, http://cessa.gforge.inria.fr) and the A4Cloud project (FP7 317550, http:// www.a4cloud.eu/). J. Garcia-Alfaro et al. (Eds.): DPM 2013 and SETOP 2013, LNCS 8247, pp. 235–249, 2014. c Springer-Verlag Berlin Heidelberg 2014 DOI: 10.1007/978-3-642-54568-9 15,
236
R.-A. Cherrueau et al.
frequently subject to general problems concerning security and interoperability. For example, the design of OAuth 2.0 has put forward simplicity instead of security when choosing to support bearer tokens, which do not require to prove the possession of a cryptographic key. Token confidentiality relies then on storage and transport security (SSL/TLS); therefore, all resources mediated via OAuth 2.0 would be exposed if the transport layer security breaks (in the following, we will use simply “OAuth” instead of OAuth 2.0). Another problem developers face when using OAuth is to actually produce interoperable implementations. The OAuth standard is not simply an authentication and delegation protocol, but an “authorization framework,” whose design was heavily influenced by enterprise use cases. In order to support thos
Data Loading...
