## 6 Authorization Mechanisms for Secure IoT Services  
Authorization mechanisms should be considered when deploying IoT services, in order to tackle possible concerns that the deployment of smart objects and services relying on them might raise in public opinion. In particular, authorization mechanisms must address the following questions:  
* Which users can access some given data? * How should the information be presented to a given user? * Which operations is a user allowed to perform? Role-based Access Control (RBAC) and Attribute-based Access Control (ABAC) are the most widespread approaches to restricting system access to authorized users. RBAC maps permissions to roles that a user has been assigned. On the other hand, ABAC maps permissions to attributes of the user. However, authorization mechanisms strongly depend on an authentication step that must have been previously taken, in order to identify users. An example of a complex, context-aware Access Control system designed for a Medical Sensor Networks scenario, which has critical privacy and confidentiality issues, is described in [75]. Just like popular Internet-based services, such as social networks, have already faced the urge to solve privacy-related problems when dealing with personal and protected data that might be made accessible to third-parties, IoT applications are also going to be facing the same issues. Since IoT services are expected to be offered in a RESTful paradigm, like those cited above, it could be helpful to borrow ideas from the experience that has been already created with Internet REST services. The OAuth (Open Authorization) protocol has been defined to solve the problem of allowing authorized third-parties to access personal user data [76]. The OAuth protocol defines the following three roles. * _Resource Owner_: an entity capable of granting access to a protected resource, such as an end-user. * _Resource Server_ (Service Provider, SP): a server hosting user-related information. * _Client_ (Service Consumer, SC): a third-party willing to access personal user's data to reach its goals. An additional role is defined: an _Authorization Server_ (AS), which issues access tokens to the client after successfully authenticating the resource owner and obtaining a proper authorization. In a general scenario, a SC, which has been previously authorized by a user, can access the data that the user has made visible to the SC. This can be achieved by letting the SC retrieve the data from the SP on the user's behalf. In order to do so, one possible approach could be to force the user to give out personal authentication credentials to the SC. This approach has many drawbacks:  
* the SC is going to appear to the SP just like the actual user, thus having unlimited access to the user's personal data;* the user cannot define different restrictions for different SC;
* the user cannot revoke the grant to a SC, unless it changes its credentials. It is thus necessary to provide a mechanism that can separate the different roles. This can be done by granting specific credentials that the SC can exhibit to the SP, which contain information about its identity and the user's identity, so that the SP can serve its requests according to the access policies that the user has defined for the SC. The OAuth protocol defines the mechanisms that are needed to grant, use, and verify these credentials, named \"access tokens\". The OAuth protocol defines the following flow of interaction between the four roles introduced above, as illustrated in Figure 5.  
1. The client requests authorization from the resource owner: the authorization request can be made directly to the resource owner or, preferably, indirectly via the AS as an intermediary. 2. The client receives an authorization grant, which is a credential representing the resource owner's authorization. 3. The client requests an access token by authenticating with the AS and presenting the authorization grant. 4.