From connected light switches to pet feeders to RVs, the Internet of Things will affect everything around us. IoT offers the prospect of a continually connected customer — as companies engage with their customers directly through their products, they have the ability to build deeper, more predictive relationships. This connectivity is a new digital channel for engagement — one that not only provides enhanced service to the customer, but also a deeper awareness of who your customer really is.
To date, there has been so much focus on connected devices that we’ve lost sight of what’s truly important: the customer. Keeping the customer front and center is critical to actually delivering the promise of IoT — especially at the IoT backend where you translate the data stream from the connected device into actions appropriate for each customer.
So how can we keep the customer at the center of all of IoT interactions? How can we inform the IoT backend who the customer is? The answer is identity standards. Specifically, a combination of JSON Web Token (JWT) and OAuth 2 Token Exchange.
Let’s take a look at the main actors:
Customer and Device Registry: This is your store of customer information and what devices customers own.
Connected Device: The connected product or device (IoT device).
An App or Interface: Constrained connected devices require an app as an intermediary between the customer and device. If your device is unconstrained, then the customer will simply interact with an interface on the device.
Device Back-end Service: This consumes the events and data from the connected device and takes action based on that data.
Here’s an overview of how JWT tokens are issued, verified, and used to secure calls to backend services for the connected device:
1. The customer is authenticated on the app/interface. Start by authenticating the customer. This is done on the app/Interface.
2. The app reads the metadata from the device, pulling attributes like serial number, model number, and the like. The app can also pull back the public key if there is one on the device.
3. Having identified the customer, the app creates a subject token to represent that customer. The app also creates an actor token to represent it, using data pulled from the device. Using Token Exchange, the app tells the Customer and Device Registry: This device (the actor) is going to act on behalf of this customer (the subject). The registry records the relationship between the two and then can kick off business processes associated with a new device registration event.
4. The registry hands back to the app a JWT which contains a little information about the device and a little information about the customer; this provides the context of all the services needed to keep the customer in the center of the interactions. The JWT can even have the key material from the device signed into it as a way of facilitating proof of possession. The app can then hand this JWT to the device.
5. The device can now present the JWT as a bearer token to the back-end service or use it in another token exchange flow. Either way the back end now has the context of who the customer.
With the customer context in hand, the back end can, based on data and events from the device, take actions appropriate to the relationship with the customer. This closes the loop and keeps the promise of IoT.
By connecting the customer and device, and by providing that relationship to the back-end service, you keep sight of the customer throughout all of the connected device’s interactions. And by maintaining constant connectivity to your customer, you essentially gain a new channel for digital engagement. Most importantly, you open a new opportunity to delight your customer. #IdentityStandardsFTW!