Fulfilling IoT’s Promise with Identity Standards
From connected light switches to pet feeders to RVs, the world of IoT promises a lot. For businesses, IoT offers the promise of a continually connected customer. This connectivity is a new digital channel for engagement – one which not only provides enhanced service to the customer, but also a deeper awareness of who that customer is. But unfortunately, this promise isn’t always kept.
The reality is that there is so much focus on the connected device, people lose sight of what is truly important: the customer. Maintaining the context of who the customer is throughout all of the interactions the IoT device has is critical to actually delivering the promise of IoT. And it is especially critical that the IoT backend, the service that is receiving and acting on the data stream from the connected device, knows who the customer is so it can take actions appropriate to the relationship between the service provider and 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! (Come on, you knew that’s that we were going to say.) Specifically, a combination of JWT and OAuth 2 Token Exchange.
Before diving into how this works. Let’s meet the main actors:
- Customer and Device Registry: This, as the name implies, is your store of who the customers are and what devices they have
- Connected Device: The IoT device
- An App or Interface: Depending on how constrained the connected device is, you might have an App that manages the device. It serves as an intermediary between the customer and device. If you device is unconstrained, then the customer will simple interact with an interface on the device.
- Device Backend Service: This consumes the events and data from the connected device and takes action
Having met our actors, let’s make this go!
- First we start by authenticating the customer. This is done on the App/Interface.
- The app reads the metadata from the Device, pulling back 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.
- Having identified the customer, the app creates a subject token to represent her. Having pulled data from the Device, the App creates an actor token to represent it. Using Token Exchange, the App tells the Customer and Device Registry: this Device (the actor) is going to act on behalf of the 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.
- 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 all of the services need 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.
- The Device can now present the JWT as a bearer token to the Backend Service or use it in another token exchange flow. Either way the Backend now has the context of who the customer is.
- With the customer context in hand, the Backend 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 backend service, you don’t lose sight of the customer throughout all of the connected device’s interactions. You can have constant connectivity to your customer; you gain a new channel for digital engagement. Most importantly, you gain a new opportunity to delight your customer #IdentityStandardsFTW!
Come by the Salesforce booth at CIS in June to learn more!
By Ian Glazer, Senior Director, Identity at SalesforceView More Posts