OAuth 2.0 as the Solution for Three IoT Security Challenges
Note: This article was originally published as a guest blog for Alien Vault.
Ideas on managing IoT in your house
While participating on the Open Interconnect Consortium Security Task Group, I offered to describe a use case for Internet of Things (IOT) security that would illustrate how OAuth2 could provide the secret sauce to make three things possible that were missing from their current design: (1) leveraging third party digital credentials (2) centrally managing access to IOT resources in a vendor neutral way; and (3) machine-to-machine discovery and authentication.
IOT physical door locks provide a concrete use case that has intrigued me for a long time–what could be more fundamental to access management than controlling who can enter your house? Wouldn’t it be great if the person could use their state-issued driver’s license to unlock your front door? Two standard profiles of OAuth2 can make this possible: OpenID Connect (to identify you using your driver’s license), and the User Managed Access protocol (UMA), to centralize policy management.
Trusted Credentials & Standard APIs
The idea of a state-issued digital credential is not that crazy. Many countries have digital identifiers. In Switzerland, you can obtain a government issued digital ID in the form of a USB stick called SwissID. But your mobile phone has the potential to be a more convenient credential than a USB stick. And this is exactly the goal of several state issued mobile driver licenses concepts proposed by Delaware and Iowa.
But what API’s will your state publish to enable authorized Web, mobile, or IOT clients to use this new mobile credential? The most likely candidate is the above mentioned OAuth2 profile for authentication: OpenID Connect. Developers are already familiar with OpenID Connect if they’ve ever used the Google authentication API’s.
So, in our hypothetical scenario, we now have our third party digital credential–a state mobile drivers license–and we have OpenID Connect API’s, published by the state, with which to identify the person who was issued the mobile drivers license. The next component to our system is a central security management user interface to enable the homeowner to manage who has the capability to access their home. Conveniently, this same Console can be used to control other IOT devices that have API’s.
Central Permission Management
The reason we need a central management user interface is simple–if every IOT device in your home has its own security management web interface, it won’t scale. There are all sorts of new decisions consumers will have to make. For example:
- Do you want to allow your TV to control the lights?
- Maybe you want to dim the lights when you put the TV in movie mode.
- Do you want your IOT grill to call the API’s of your IOT fire alarm?
- Who can enter your house, using what credentials?
- Who can see my pictures on my cloud file storage provider?
Using a central policy decision point, people can manage in one place which policies apply to what, without having to go to the web admin page of every device. For short, let’s call this thing the “Console.”
So let’s walk through in a little more detail how this use case would work:
- The homeowner would configure their Console to rely on the OpenID Provider (OP) of certain domains. For this example, let’s say there are two domains: 1) mystate.gov and 2) the local domain for your house. You might want a local domain to manage accounts for people who don’t have a driver’s license, like your young kids. For people in your local domain, you’ll also have to manage their credentials, i.e. passwords. This might be a pain in the neck, but at least you don’t have to manage users for every IOT device in your house.
- Using OpenID Connect Discovery, the Console could immediately find out the local and state OpenID Connect API URLs, and other information required to securely identify a person at the external domain. The OpenID Connect Discovery spec is very simple. Just make an HTTPS GET request to https://
/.well-known/openid-configuration. This will return a JSON object with the URLs for the API’s of the OP, and other information your Console will need, like what kind of cypto is supported, and what kind of authentication is available. If you want to see an example of an OpenID Connect Discovery response, check out Gluu’s OpenID Connect discovery page.
- Next your Console would dynamically register itself as a client with the state OpenID Connect Provider (OP) using the OpenID Connect dynamic client registration API. Once completed, the Console will be able to authenticate a person in the respective domain.
- The person using the console could then define a policy that describes how a person entering the house should be authorized–for example, using what credentials and during what time of day.
- The door lock would use OpenID Connect Discovery and Dynamic Client Registration to register itself with the Console.
- The door lock would rely on the console to handle the person’s authentication. The console would call the OpenID Connect authentication APIs at the state, which could result in the state sending a PUSH notification to the person’s pre-registered mobile device. The person might see an alert that says something like “10 Oak Drive Security System wants to verify your first and last name. Is it ok to release this information?” Once approved, the policy decision point can use that information for policy evaluation. For example, perhaps I made a policy that said to let John Smith enter my house from 10am – 2pm. A PUSH notification could be combined with biometric, cognitive, or other physical tokens to make the identification multi-factor. The policy in the Console could even require one of these mechanisms by specifying a specific ‘acr’, that would be provided as part of the response by the state OpenID Connect provider.
- The Console has a few ways it could handle enrollment–which users are allowed to enter the house. Access requests could be queued for approval by the homeowner, or perhaps the homeowner registers the person in advance.
- What would the interface look like for the door lock? How would the person assert who they are, or enter their username and password for locally managed credentials? Here are a few ideas: the person could enter a short URL on the mobile browser of their phone; the person could read the URL via NFC; a smart service provider could provide an app that uses the geolocation to find the nearest lock.
Of course the door lock might have some fallback mechanisms. Perhaps if Wifi is down, the door might fallback to some kind of proprietary Bluetooth mechanism. Or have a physical key, like a USB key that opens the lock. Or even a high-tech piece of metal, cut in a special unique way that fits into a mechanical unlocking apparatus! Now that would be cool! Oh wait, that’s the key we have today!
Subscribe to Get News and Product Updates
our RSS Feed