It was buried in the final use case of the Proof of Concept (POC) document but it intrigued me straight away.
"The following proof point is considered 'should' or 'optional' for the POC execution, time permitting: Authentication - Present a wearable device instead of PIN."
The POC was for a prospect that wanted to see how OAuth 2.0 could help them deliver a new and innovative Internet Banking (IB) app to the mobile devices of their customers. The rest of the POC was straightforward, although non-trivial: build an iOS app for an IB scenario.
I would need to configure the device registration and user authentication using PingFederate, and the authorization requirements using PingAccess, making use of the OAuth 2.0 and OpenID Connect 1.0 standards.
A user could register multiple devices. The registration flow involved authentication via a pre-registered username and password, followed by a one-time password. The user would then be required to set a PIN, to be used for subsequent sign-ons.
But "Present a wearable device instead of PIN" to authenticate themselves? Hmmm.
I first wondered which device could I get a hold of for the demonstration. And what would be involved in the integration? I only had days to create the complete demo.
I pinged my colleagues and found that we had ongoing discussions with several wearable device companies. Wearables and novel two-factor authentication methods are the "New New Thing" in the IT security industry, and the range of options was astounding. There were a number of fitness bands, including one that claimed to read a user's unique heartbeat as a form of credential. Another app allowed the user to physically knock on their device to authenticate themselves. And then there were smart watches, Google Glass, even inserts for jewelry. Could any of these be used for authentication?
None of these, however, had been integrated with PingFederate as an authentication method for me to use in my demo. So I decided to work with what I had available. On my wrist was a Jawbone UP24, a gift from my wife, who is the founder and CEO of a specialist personal training company. It had been given to me in an attempt to use technology to seduce me back into exercise. I now walked and ran (fairly) regularly and reviewed my progress via Jawbone's app on my iPhone.
Jawbone doesn't provide direct access to the band via Bluetooth, so developers must use the Jawbone REST API to access their Cloud service, and there was an iOS SDK available on GitHub. Integrating it into my IB app was quick and easy.
First the user must connect my IB app to the Jawbone app and give permission for the IB app to retrieve data from the Jawbone Cloud service. To enable this, an OAuth 2.0 Authentication Code flow is triggered. The user must authenticate themselves to the Jawbone service and authorize the OAuth scopes being requested by the IB app.
My app can then queries the Cloud service for information about the user.
In my demo, the app requests additional authentication using the Jawbone if the user attempts to transfer more than $2,000 to another bank account. This is communicated to the app via an HTTP response code returned by PingAccess, which evaluates each request to the back-end core banking system API (in this case, a REST API written in PHP) against its access control policies.
But how should I have the user validate that they are in possession of the band at the time of transferring the money?
In an unrelated internal discussion on the subject of wearables, one of my colleagues suggested a particular gesture could be performed and then detected: three arm circles clockwise, followed by three counterclockwise. I'm pretty sure he was joking.
Aside from the fact that this would be embarrassing for the user in a public place, it would also give onlookers an obvious clue that the user was performing certain actions: "Look, that guy waving his arm around is transferring money using that Internet Banking app!"
A press of the Jawbone's button would be unobtrusive so I designed the app to display a page requesting the user put their band into Sleep Mode. The app uses the Jawbone BandEvent API to receive details of the button press.
For this demo I had the IB app call the Jawbone API - the implication being that it needs to know when to make that call and have the logic of deducing from the responses the user's authentication. In a real deployment, it would be PingFederate making that API call, based on the adaptive authentication policies managed there.
I also realized that a single button press wasn't going to be enough to authenticate the user. It's plausible that an attacker could time an attack to coincide with a single button press, so the app requests the user to press the button a second time to trigger an Exit Sleep Mode event.
When this second event is detected, the app resends the transfer money API request with an extra HTTP parameter, telling PingAccess that the authentication has succeeded. PingAccess then allows or denies access to the core banking API.
This was OK for the demo; but in a production system, I would register the band in the server-side device registration database and provide a REST API for PingAccess to validate that the user and the band were associated.
There are definite business benefits for using this type of tech for authenticating users. It removes the need in many cases for a company to pay for expensive hardware tokens, or pay for an SMS service to transfer one-time passwords for everyday transactions that require a second authentication factor.
It's also something personal to the user themselves that they aren't likely to share with others, which is a problem with tablets and phones, as any parent with young children knows. And, even more so than a phone, the user is likely to always have this sort of wearable with them.
The demo has been well received by many of my customers who are looking for standards-based mobile app authentication and authorization. And as identity federation, access management and Single Sign On isn't the sexiest of demonstrations, I really enjoy their looks when I use my Jawbone band to authenticate myself. It's the coolest thing I've done in my job at Ping Identity!
Mark Perry is a Regional Solution Architect in the Asia Pacific region for Ping Identity.