The Native Applications (NAPPS) Working Group effort at the OpenID Foundation is profiling OpenID Connect to enable a Single Sign-On (SSO) model for native mobile apps.
The NAPPS model introduces a Token Agent (TA) onto the phone/tablet, to which the user goes through an explicit sign-in and authorization process - resulting in the TA being issued a number of tokens. This initial flow is vanilla OAuth/Connect.
The SSO magic happens when the TA uses those tokens to obtain additional tokens that can be handed over to other business apps (e.g. Salesforce, on-prem etc.) on the device. Those business apps use the tokens on their API calls just as if they were obtained in the default manner, i.e. by engaging directly with an Authorization Server (AS), getting the user authenticated, grabbing consent, etc. The user logs in only to the TA, but all the other (relevant) native apps just work - thus SSO.
That's a powerful idea. But it complicates the user consent model, which is a key component of OAuth and Connect and a consent step may be mandatory, depending on the use case.
When each individual business application obtains their own tokens by directly interacting with the Authorization Server, obtaining consent is straighforward. When initially authenticating the user (preferably via the mobile browser), the AS can obtain the user's consent for the relevant scopes and store them away against that client identifier. But if it's the TA that obtains tokens on behalf of the business apps, and so the business apps do not directly control the consent experience - how can we be sure that the user is fully aware (and approving of) the data access that will be enabled through the TA?
Note: While user consent may be critical in a consumer scenario, some see it as optional in an enterprise context - consent arguably implicit in the employee accepting the bi-weekly paycheck. Nevertheless, we'll assume in the following that it is necessary to obtain the employee's consent for the enablement of applications they use to access business data.
One possible model (the simplest) is that, at the time of authentication to the TA, the AS obtains consent for all the individual business applications that will be subsequently enabled - creating a consent UI for an employee something like
Of course, the number of native applications that an employee will use is only going to increase, or the enterprise may choose a different CRM provider etc, so this initial list may quickly be out of date. More flexible for dealing with future changes would be a consent UI like
Privacy advocates, however, might not like the coarse granularity of these models.
The first model hides a thornier issue. Some of those applications in the above list are likely engineered to collect their own consent. For instance, it's all well and good for the above UI to say that consent is being collected for the Salesforce (just as an example, though a representative one of the requirement) application on the phone, but Salesforce already has their own OAuth/Connect infrastructure that presumes it will collect (and record) its own consent. And, of course, a related complication is that the Salesforce APIs the Salesforce apps will call expect to see access tokens issued by their own Authorization Server.
To deal with the second issue, the NAPPS WG is defining a flow whereby the TA can interact with the Salesforce AS to obtain a token that a Salesforce API would 'recognize', i.e. issued by the AS it already knows and trusts. This model is represented by the diagram below
This flow leverages the id_token that Connect provides us, and uses the JSON Web Token (JWT) Assertion flow between the TA and the Salesforce AS in order to deliver an access token back to the TA. Once handed that token, the Salesforce app uses it on its API calls.
OK, that's nice. But it still doesn't resolve the consent issue. Namely that the Salesforce AS may be unwilling to return the access token to the TA until it has itself interacted with the user and obtained consent for that REST call at the bottom of the flow. For that to happen, the user's browser has to load the Salesforce authorization endpoint - at which the user's consent can be collected.
To enable that, NAPPS is defining a model where the TA can facilitate sending the browser to the appropriate Salesforce endpoint and critically, do so such that the user would arrive in an authenticated state (i.e. with a token representing the user's identity). Glossing over some details (that some will argue are important), the flow looks like
This sequence leverages the AppInfo endpoint of the NAPPS spec, a (currently under-specified) piece of the NAPPS framework from which the TA can obtain metadata about the applications under its domain. Here the metadata for the Salesforce app would include a URL that, when handed to the browser, would enable an authenticated SSO session into the Salesforce AS page.
Aside: Interestingly, the above flow could be used by the TA to deliver the user's browser (in an authenticated state) to an arbitrary application address and not just an Authorization Server endpoint. Consequently, a TA could facilitate an SSO experience to both native and web apps.
The NAPPS WG is currently discussing the best model for what happens after the consent is obtained in the last step of the above flow. Should the Salesforce AS return an authorization code to the TA - to be exchanged for the desired access token in the typical manner? There are some advantages to a model where the Salesforce AS, having recorded consent, returns no such code. Instead, the TA would exchange an id_token (as in the first sequence diagram). Discussion continues.
If the above flows appear intimidating and complex (they were a bit to draw), I'll point out two things
Native applications and their corresponding APIs are insulated from that complexity - the burden is taken on by the TA and the different Authorization Servers.
For the most part, the flows leverage existing bits of OAuth and Connect, e.g. id_tokens, JWT Assertion profile, Connect's support for response=none etc.