OAuth: a web authorization framework

In the previous section, we gave a brief introduction to API tokens, how they work, and how you can implement them on web Things. API tokens are a good starting point, and along with encryption (TLS), they are arguably the bare minimum a WoT device should offer in terms of security. But as soon as we need to share the resources of a device with several users having different authorization rights, simple API tokens like the ones we’ve introduced present two challenges.

First, we need a process for web applications to generate and retrieve tokens dynamically, ideally through an API. Obviously, we can’t just create an API endpoint that returns tokens. This would be insecure and we’d be back where we started because we’d need to secure that API as well. Besides, creating a bespoke mechanism to get tokens wouldn’t foster interoperability; it would make the process complicated and bespoke for each device and/or API.

Second, API tokens shouldn’t be valid forever. API tokens, just like passwords, should change regularly. We should also be able to invalidate any token manually when needed. This ensures that when an API token has leaked, we can disable it. But again, creating a custom API to renew tokens wouldn’t foster interoperability between web clients and web Things.

What to do? It turns out there’s a web standard coming to our rescue: OAuth.1 OAuth is an open standard for authorization and is essentially a mechanism for a web or mobile app to delegate the authentication of a user to a third-party trusted service; for example, Facebook, LinkedIn, or Google. OAuth makes this delegated authentica- tion process secure and simple by dynamically generating access tokens using only web protocols. OAuth also allows sharing resources and between applications. For instance, you can allow some of your Facebook friends to securely access some of your documents on Google.

In short, OAuth standardizes how to authenticate users, generate tokens with an expiration date, regenerate tokens, and provide access to resources in a secure and standard manner over the web. Sound like exactly what we need, doesn’t it? Let’s see

secure tokens but also offers a standard mechanism to send encrypted payloads over insecure connections. In other words, JWT makes it possible to send secure con- tent over HTTP and WebSocket packets without using TLS. This is particularly appeal- ing for the WoT because it removes the self-generated certificate warnings in the browser you encountered earlier because certificates aren’t required for interactions between an app and Thing within a local network. It’s certainly not as standard and battle-tested as TLS, but we’ve had some promising results in our own tests. There are JWT libraries for many languages including Node.js, so go ahead and give it a try!

96 CHAPTER 9 Share: Securing and sharing web Things

how to do this in practice using the most recent version of the OAuth standard: OAuth 2.0.

OAUTHROLES

A typical OAuth scenario involves four roles:

 A resource owner—This is the user who wants to authorize an application to access one of their trusted accounts; for example, your Facebook account.  The resource server—Is the server providing access to the resources the user wants

to share? In essence, this is a web API accepting OAuth tokens as credentials.  The authorization server—This is the OAuth server managing authorizations to

access the resources. It’s a web server offering an OAuth API to authenticate and authorize users. In some cases, the resource server and the authorization server can be the same, such as in the case of Facebook.

 The application—This is the web or mobile application that wants to access the resources of the user. To keep the trust chain, the application has to be known by the authorization server in advance and has to authenticate itself using a secret token, which is an API key known only by the authorization server and the application.

The flow of a typical OAuth-delegated authentication mechanism is shown in figure 9.6. At the end of the token exchange process, the application will know who the user is and will be able to access resources on the resource server on behalf of the user. The application can then also renew the token before it expires using an optional refresh token or by running the authorization process again.

Application

Authorization request

Authorization grant

Authorization grant from user, app ID, and app secret

Access token; refresh token (optional)

Access token

Protected resource

User Authorization server Resource server

Mobile app Lena Heater Heater

Figure 9.6 OAuth delegated authentication and access flow. The application asks the user if they want to give it access to resources on a third-party trusted service (resource server). If the user accepts, an authorization grant code is generated. This code can be exchanged for an access token with the authorization server. To make sure the authorization server knows the application, the application has to send an app ID and app secret along with the authorization grant code. The access token can then be used to access protected resources within a certain scope from the resource server.

97

The Social Web of Things

OAuth has become a successful protocol, and as a consequence, a large number of services on the web such as social networks (for example, Facebook, Google+, Linke- dIn, and Twitter), developer services (for example, GitHub and BitBucket), and many other websites (such as TripAdvisor and Meetup) support OAuth. But what about the IoT? How does OAuth relate to our web Things?

OAUTHANDTHE WEBOF THINGS

For a start, if all Things become OAuth servers in place of generating API tokens, web clients will then have a standard way to obtain tokens to access the resources of devices.

Let’s get back to our hotel scenario once again. Lena is the user in figure 9.6 and she has a user account on the heater unit of figure 9.2, which is both the authorization server and the resource server. Lena uses a mobile app to control the heater, as shown in figure 9.6. The application asks Lena to log into the heater with her user account, and then the application exchanges the resulting authorization grant for an access token from the heater unit. The heater unit accepts the access token and provides access to the heater to the application on behalf of Lena.

If Lena was interacting with her heater in her home, this would be a practical sce- nario. But in the case of the hotel, that means that the heater and all other devices would need to know about Lena and all the other hotel clients. Besides, all devices would also need to know all the applications that would interact with them and would need to have generated a secret token for each of them. It’s pretty obvious this approach would be a nightmare to maintain!

Implementing an OAuth server on a Linux-based embedded device such as the Pi or the Intel Edison isn’t hard because the protocol isn’t really heavy. But maintaining the list of all applications, users, and their access scope on each Thing is clearly not going to work and scale for the IoT. We’ll look at a better approach in the next section.

9.3

The Social Web of Things

Using OAuth to manage access control to Things is tempting, but not if each Thing has to maintain its own list of users and application. This is where the gateway integra- tion pattern we discovered in chapter 7 can help. What if you had only a single proxy that would know the Things you have at home (or in the entire hotel) and also know the various users involved, so it could manage access control in place of these Things? “But then I still have to create user accounts on this proxy for each user,” we hear you

The nerd corner—I want my Pi to be an OAuth server!

If you do want to turn your Pi into an OAuth server, go ahead! It will be a good exercise to help you better understand the protocol and will actually make the implementation in the next section more secure. A good place to start is the node-oauth2-server Node.js module for Express, which should run seamlessly on your Pi, Edison, or Bea- gleBone.

98 CHAPTER 9 Share: Securing and sharing web Things

say. Of course, you could do that, but a much better approach would be to use the notion of delegated authentication offered by OAuth, which allows you to use the accounts you already have with OAuth providers you trust, such as Facebook, Twitter, or LinkedIn.

Not only does this approach allow you to reuse the user accounts you already have in other web services, but it also allows you share access to your devices via existing social network relationships. These concepts are often referred to as the Social Web of Things.1 _{Let’s see what this would look like in more detail. As with all things security,} this won’t be the easiest ride but will definitely be a rewarding one.