- Unsupervised Learning
- Posts
- Moving Application Authentication to the Operating System
Moving Application Authentication to the Operating System
Benedict Evans said something on Twitter the other day that got me thinking a lot about the future of app authentication.
He’s highlighting a pain that we all experience but that we accept as necessary, like a barbed wire watch band. And it absolutely does feel like something we will eventually fix. The question is when.
I’ve been talking for a while about how good applications become OS features. I argue that new tech features follow this timeline:
The feature starts as a standalone application.
If it’s popular it’ll be adopted by social media platforms.
If it’s really compelling then it’ll eventually make it into the operating system.
There are multiple examples of this: location sharing, heart rate monitoring, workout tracking, weather, stopwatches, calculators, voice assistants, etc. It’d be enough to scare me out of being an application developer: the better your app does the faster it’ll become part of iOS and Android.
Anyway, Benedict’s point was about authentication. Why do we have all these separate logins for every application when it’s one of the worst user experiences in all of tech?
As I was thinking about it I realized that we’ve already gone through two of the phases in the App/Social/OS evolution. Password applications solve this problem by saving your passwords for you to make it easier to enter them. And Facebook and Google provide OAuth functionality so you can register and log in using your social credentials in a more transparent way.
Having an app to do it is easier than manual (step 1), and having your social network do it is easier than using an application (step 2). Now we’re just waiting for the final step, which is having the OS do it for us automatically.
And who better to know about us than our operating system? As digital assistants become more prominent, along with constant and often passive IoT interactions that will be made on our behalf, we’re going to be authenticating to services constantly. Manual interaction (and credential management) will not be an option.
Unsupervised Learning — Security, Tech, and AI in 10 minutes…
Get a weekly breakdown of what's happening in security and tech—and why it matters.
Future authentication
I think the only option for us is to solve authentication’s last mile problem, which will allow us to prove not just that a device made a request, but that the right person was using that device. This is the link that must occur in order for our operating system to be able to represent us.
As I talk about in that piece, this means constantly taking multiple authentication points from us, from our gait, to our voice, to our typing patterns, ambient noise, motion sensors, and dozens of other inputs—and then using that to maintain a constantly updating authentication score.
An Active Authentication Mock-up
This score updates every few seconds, and it’s a representation of how sure the OS is that you are you.
Then, when it comes time to authenticate to a service—say to open the door to your hotel just by touching the handle, or to log you in to Facebook without an extra step—your OS will do the following:
Form a request to the authentication API for what you’re trying to do (hotel door or Facebook).
Attach the current—up to the second—security score.
Sign that request, combined with your score, with the private keys of the device and user.
Send that request to a third-party Identity Validation Service, which validates that people really are who they say they are. They in turn have their own Active Authentication Score, similar to that of the OS, but they can also see where all this user has tried to authenticate recently, so they know if this particular request is likely to be fraudulent.
The Identity Validation Service then looks to see the security level required for this action—say a 65 is required to get into Facebook, but a 70 is required to open the hotel door—and if the current AAS is higher than the requirement for the service, it will sign that signed request with its own keys and send that to the service in question.
The hotel door, or Facebook, or whatever will then see a request from the device, signed by the IVS that it trusts, with a sufficient AAS score, and it allows the request.
There are a lot of steps there, and hence a lot of requests. And it doesn’t address what happens when the IVS service goes down, or is slow, or gets DDoS’d. But you get the idea. Those are engineering and security challenges, and their existence will require optimization and resilience, but they likely won’t stop something like this design from happening.
Anyway, I wish I had thought of Benedict’s point. Application authentication really is just another feature that will eventually end up being handled by the OS. And for me it can’t come fast enough.