OAuth2 as the solution for Three IoT security challenges

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 Delawareand 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.”


  • On its own OAuth2 is a framework, and does not specify how to implement a particular use case. OAuth2 defines several flows for person and device authorization. It does not specify anything about token formats (JSON or XML?), encryption formats, or other specific implementation details. To do this you can create a “profile” of OAuth2. The two most notable profiles are 1) OpenID Connect, which defines person authentication, client authentication, client registration, and 2) the User Managed Access (UMA) protocol, which defines a profile of OAuth2 that enables a policy enforcement point (i.e. a web server) to authorize a request from a central policy decision point (i.e. the authorization server).

    Facebook was an early adopter of OAuth2, and implemented some of the first applications that asked a person to authorize something. Over the years, these patterns were adopted by others in the consumer IDP industry, like Google and Microsoft. The best practices and gotcha’s were documented and shared with everyone, and have become OpenID Connect. Adopting OpenID Connect makes sense for your domain because you can take advantage of the best practices established by the best in the industry to manage their OAuth2 authentication service.

    This is where profiles of OAuth2, like OpenID Connect and UMA, succeed in standardizing solutions for today’s distributed authentication and authorization challenges. Its just too complicated to roll-your-own OAuth2 security service. Sure, older protocols like SAML and CAS may still provide tactical value for your organization, but here are 5 reasons why OpenID Connect and UMA should be a top priority for your modern identity and access management infrastructure.

    1) Alignment with OAuth2 standards is critical for mobile, IOT and Web security.

    By aligning with OAuth2 you can support both today’s and tomorrow’s access management challenges, including mobile single sign-on, multi-factor adaptive authentication, and federated access to third-party cloud resources.

    2) OpenID Connect levels the playing field for identity providers and developers.

    By supporting OpenID Connect your organization can essentially run the same federation infrastructure as the worlds most trusted identity provider, Google. If any one organization has seen and dealt with today’s most sophisticated authentication challenges, it’s undoubtedly Google. In addition, OpenID Connect is pretty much a JSON / REST architecture which is light on the wire and well understood by modern web developers.

    3) OpenID Connect includes discovery

    As OpenID Connect continues to gain adoption, gone will be the days of the Nascar Login. Replacing all those various “log in with” buttons will be one OpenID Connect button that enables any user, to use any email, at any domain, for authentication–assuming that the chosen domain supports OpenID Connect and the user attached to that email has the necessary attributes (i.e. group affiliation, title, etc.) needed to access the resource. Simply make a request tohttps:/.well-known/openid-configuration, which enables a domain to publish their public keys and other configuration information needed by developers. For example, check out Gluu’s OpenID Connect Discovery Page.

    4) UMA enables organizations to launch new, more secure APIs that provide a top-line opportunity, not just a cost.

    If you can’t control who or what can access an API, and when, then you can’t charge for its use. UMA provides a standard way for API owners to protect and control access to APIs in a distributed, scalable way.

    5) UMA enables trust elevation by enabling your organization to set policies for certain API’s that require certain credentials, for instance two factor authentication.

    A single authorization point is no longer sufficient for serious website security. To limit the damage done by hackers, domains now need to use a multi-layered security approach where authorization is continually checked for depending on what resource is accessed, by which person, on which device, from where, and when.


    A strong, centralized, and modern identity and access management infrastructure is one of the most important security tools available today. The majority of breaches are due to compromised credentials, and aligning with modern standards that support today’s requirements for authentication and authorization can greatly reduce your exposure to fraud.

    While IAM software has historically been expensive and proprietary, there are now open source options available (like the Gluu Server!) that enable domains to enforce better security at a more affordable total cost of ownership (TCO).

    If you don’t want your organization plastered on the front page of tomorrow’s newspaper due to an embarrassing breach, do yourself a favor and upgrade your identity and access management infrastructure today.

Sign In or Register to comment.