One of Ping's financial services customers is building out the identity and authentication architecture for their native mobile application and its associated Apple Watch application. Both applications--on the phone and on the watch--will make calls to cloud endpoints in order to pull down the relevant customer's financial data.
This use case presents an interesting twist on "normal" mobile applications. With two devices and two applications, the challenge is how to use OAuth 2.0 to authenticate those calls in an efficient and cohesive manner.
The customer needs to account for two high-level requirements:
The more limited battery life of the watch
Differentiated permissions between the two apps (i.e., the watch app can read data but not initiate transactions)
Apple Watch is WiFi-enabled, so it could possibly send a REST call to a cloud API endpoint. This can be done in two different ways, each with potentially different implications for the identity and authentication model:
Indirect via BLE to a paired iPhone (itself with cellular or WiFi) with the REST call using an access token previously issued to a) the watch app or b) the phone app
Direct via WiFi with the REST call using an access token previously issued only to the watch app
Considering the customer's requirements listed above, let's see how each of these options for identity and authentication models is impacted.
Simply running a radio can have a significant drain on the Apple Watch battery. Because the bluetooth low-energy stack uses less power than WiFi on the watch, preserving battery life on its own would argue for the first option. In this case, the watch connects to the Internet via the nearby phone's connection and not directly.
For the cloud API to differentiate between the watch and phone applications (and restrict greater-sensitivity operations to the phone, for instance) the two applications must have different access tokens (the watch token might have fewer OAuth scopes attached). In this model, the watch app needs its own access token. Meeting both requirements consequently leads us to option 1(a) above, where the watch relies on the phone's connection but uses its own access token--not the access token issued to the phone app as in option 1(b).
How the watch app gets its access token is a different issue. The phone app can follow the normal OAuth flow to get its own set of tokens, but the normal OAuth flow doesn't address how to hand a different, reduced-scope token to the watch app (or store it on its behalf). The NAPPS Token Agent model may no longer be relevant for this sort of secondary token sharing between native apps, but it could play a role in this sort of multi-device use case.
Many IoT devices, like the Apple Watch, will be constrained in some manner (battery life, CPU capacity or connectivity). The good news is that the IETF's work group, Authentication and Authorization for Constrained Environments (ace), is already exploring how such constraints need be addressed in authentication and authorization frameworks, which we just explored here.