The idea of the Social Web of Things is to create an authentication proxy that controls access to all Things it proxies by identifying users of client applications using trusted third-party services. The detailed steps for this workflow are shown in figure 9.7.
Again, we have four actors: a Thing, a user using a client application, an authenti- cation proxy, and a social network (or any other service with an OAuth server). The client app can use the authentication proxy and the social network to access resources on the Thing. This concept can be implemented in three phases:
1 The first phase is the Thing proxy trust. The goal here is to ensure that the proxy
can access resources on the Thing securely. If the Thing is protected by an API token (device token), it could be as simple as storing this token on the proxy. If the Thing is also an OAuth server, this step follows an OAuth authentication flow, as shown in figure 9.6. Regardless of the method used to authenticate, after this phase the auth proxy has a secret that lets it access the resources of the Thing.
2 The second phase is the delegated authentication step. Here, the user in the client
app authenticates via an OAuth authorization server as in figure 9.6. The authentication proxy uses the access token returned by the authorization server to identify the user of the client app and checks to see if the user is authorized to access the Thing. If so, the proxy returns the access token or generates a new one to the client app.
3 The last phase is the proxied access step. Once the client app has a token, it can
use it to access the resources of the Thing through the authentication proxy. If the token is valid, the authentication proxy will forward the request to the Thing using the secret (device token) it got in phase 1 and send the response back to the client app.
In order not to leak any tokens at any step, all the communication has to be encrypted using TLS. The details for each phase are summarized in figure 9.7.
1 The Social Web of Things was a concept developed in Dom’s thesis (http://webofthings.org/2011/12/01/
phd-web-of-things-app-archi/) based on the Friends and Things project: http://webofthings.org/2010/02/ 02/sharing-in-a-web-of-things/.
99
The Social Web of Things
LEVERAGINGSOCIALNETWORKS
You might have noticed that we overlooked one step in the process: how does the auth proxy know what resources a user can access, or even if they can access any resources at all? Someone needs to configure the proxy with a number of user identifiers
Auth proxy
Give me a token, this is my secret
Secret token
Redirect to Facebook
Please login
Here are my credentials
Redirect to auth proxy
Redirect to auth proxy
Give me a Facebook access token
Facebook access token
Check user, store/generate user token
Give me access to /temp
Redirected to Facebook
Give me access to /temp, here is my user access token
Give me access to /temp, here is my secret token
Temp is 77°F
Temp is 77°F
Use this user token to access resources
Thing Client app Facebook
Auth proxy Thing Client app Facebook
Phase 1: Thing proxy trust (e.g., via OAuth), refresh on expiration
Phase 2: Delegated authentication via OAuth server (e.g., Facebook, Twitter)
Phase 3: Proxied access via OAuth server (e.g., Facebook, Twitter)
Figure 9.7 Social Web of Things authentication proxy: the auth proxy first establishes a secret with the Thing over a secure channel. Then, a client app requests access to a resource via the auth proxy. It authenticates itself via an OAuth server (here Facebook) and gets back an access token. This token is then used to access resources on the Thing via the auth proxy. For instance, the /temp resource is requested by the client app and given access via the auth proxy forwarding the request to the Thing and relaying the response to the client app.
100 CHAPTER 9 Share: Securing and sharing web Things
corresponding to the users who can access the system along with a list of resources they can access. In the case of our hotel, we could ask the guests to log in with their Facebook accounts or, even better, with the Booking.com profile they used to book the hotel room in the first place! Then we could save their social identifiers in the auth proxy, along with the paths to the devices in their room. In the case of a home automation system, you can even imagine granting access to lists of friends or rela- tives. Figure 9.8 is an example of a user interface on the auth proxy that can let you share resources with your friends.
Figure 9.8 User interface of a Social Web of Things authorization proxy: First (upper left), the UI allows the user to select a Thing to be shared and (lower left) the resource of the Thing that should be shared; for example, /temperature. Then (upper right) it lets the owner of the Thing log into their social network, such as Facebook, and (lower right) select a friend to share with or a list of friends. Here we share the temperature sensor of the Spot1 device with Dom’s sister via Facebook. [Source: Friends and Things Social Web of Things project1]
The good news is that nothing here needs to be hard-coded. Thanks to the fact that our Things speak web (see chapters 5 and 6), we can discover their resources (see chapter 7) and map them to our connections on various OAuth-compliant social net- works! This is the very idea of the Social Web of Things: instead of creating abstract access control lists, we can reuse existing social structures as a basis for sharing our Things. Because social networks increasingly reflect our social relationships, we can
101
The Social Web of Things
reuse that knowledge to share access to our Things with friends via Facebook, or work colleagues via LinkedIn.