NAPPS has left the building (but is still on the front lawn)

A good standards effort defines specifications that build on the existing stack of underlying protocols, cryptographic techniques, data formats and platform capabilities. A better standards effort defines specifications that can adapt accordingly as that existing stack changes and evolves. The very best standards efforts know when to announce victory, pack their bags, and go home when that stack evolves in such a way to mitigate the value of the standard in the first place.

By this measure, NAPPS, the OIDF WG chartered to define mechanisms in support of an SSO experience for native applications, is an awesome standards effort.

As has been previously pointed out by John Bradley and myself, the mobile OSs are evolving their support for native SSO, both iOS and Android are adding new features that make SSO possible 'out of the box', without the introduction of specialized application software on the device, as the NAPPS group had been proposing. Consequently, the value of the 'Token Agent' model that NAPPS was proposing and standardizing is diminished - fundamentally we don't need to supplement the mobile OSs to achieve native SSO when they provide sufficient capabilities on their own.

Consequently, as John writes, the NAPPS WG is 'pivoting' and, rather than delivering a normative specification for the Token Agent role, will instead:

"...document best practices for Single Sign-on for Enterprise and Software as a Service Providers using these new features in combination with the PKCE specification, as well as filling in any remaining gaps to allow SaaS providers to fully support OAuth and OpenID Connect enabled native applications in a secure way without forcing users into extra unproductive logins."

In addition to these sort of guidelines, there is discussion about the development of open source SDKs that would wrap up all these features and flows - simplifying for application developers how to hook into this native SSO model. Discussions are underway as to where development of these libraries make sense.
Interestingly, while the value of a Token Agent has been marginalized by the new mobile OS features for the native SSO use case, the TA model may yet find a home in the Internet of Things.

Many IoT devices are characterized by limited UI capabilities for display and user input - both of which are critical for the initial binding of the device to a user account and corresponding provisioning of credentials. But if Things are constrained in this way, mobile devices aren't - and so can facilitate this initial setup step.

Shown here is a scenario where a native application on a device plays the role of a Token Agent on behalf of a Thing. The TA obtains an OAuth access token for the Thing and then delivers that token using some short range wireless protocol such as BLE or NFC. Once the Thing has its token, it can use that to authenticate itself when interacting with cloud endpoints or even other Things.


Should the TA model be eventually applied to IoT use cases, perhaps my not insignificant $$ investment in a large supply of 'There is nothing token about my agent' t-shirts will not be wasted. Let us hope.

NAPPS - a rainbow of flavours

Below is an arguably unnecessarily vibrant swimlane of the proposed (Native Appplications) NAPPS  flow for an enterprise built native application calling an on-prem API.

The very bottom arrow of the flow (that from Ent_App to Ent_RS) is the actual API call that, if successful will return the business data back to the native app. That call is what we are trying to enable (with all the rainbow hued exchanges above)

As per normal OAuth, the native application authenticates to the RS/API by including an access token (AT). Also show is the possibility of the native application demonstrating proof of possession for that token but I'll not touch on that here other than to say the corresponding spec work is underway).

What differs in a NAPPS flow is how the native application obtains that access token. Rather than the app itself taking the user through an authentication & authorization flow (typically via the system browser), the app gets its access token via the efforts of an on-device 'Token Agent' (TA). 

Rather than requesting an access token of a network Authorization Service (as in OAuth or Connect), the app logically makes its request of the TA - as labelled below as 'code Request + PKSE'. Upon receiving such a request from an app, the TA will endeavour to obtain from the Ent_AS an access token for the native app. This step is shown in green below. The TA uses a token it had previously obtained from the AS in order to obtain a new token for the app. 

In fact, what the TA obtains is not the access token itself, but an identity token (as defined by Connect) that can be exchanged by the app for the more fundamental access token - as shown in pink below. While this may seem like an unnecessary step, it actually

1. mirrors how normal OAuth works, in which the native app obtains an authz code and then exchanges that for the access token (this having some desirable security characteristics)
2. allows the same pattern to be used for a SaaS app, ie one whether there is another AS in the mix and we need a means to federate identities across the policy domains. 

When I previously wrote 'TA uses a token it had previously obtained from the AS', I was referring to the flow coloured in light blue above. This is a pretty generic OAuth flow , the only novelty is the introduction of the PKSE mechanism to protect against a malicious app stealing tokens by sitting on the app's custom URL scheme.