When you don't have anything nice to say, well then perhaps its time consider a career as an analyst.

Wednesday, October 08, 2014

A symmetrical NAPPS model

The NAPPS WG in the OIDF is defining a framework for enabling SSO to native applications.

One challenge has been in supporting 3rd party native applications from large SaaS that already have an OAuth & token infrastructure (Salesforce as an example).

For this sort of SaaS, NAPPS has to allow the SaaS's existing OAuth AS to issue the token ultimately used by the app on the API calls.

The NAPPS spec is evolving to dealing with such applications in almost exactly the same way as it does native applications that call on-prem APIs built by the enterprise.

Fundamentally, for both categories of native applications, the enterprise AS issues to the Token Agent an identity token JWT, this handed to the application through the mobile OS bindings. The app exchanges this JWT for the desired access token to be used on API calls - the only difference is the AS at which the JWT is exchanged.

Local native apps

app requests
tokens of TA, includes generated nonce

TA uses its RT to send
request + nonce to AS

AS returns PoP JWT

TA hands over PoP JWT to
app

App exchanges JWT, shows PoP

AS returns token(s) to app

3rd party native apps

app requests tokens of TA, includes generated nonce

TA uses its RT to send request + nonce to AS1

AS1 returns PoP JWT,
targeted
at AS2

TA hands over PoP JWT to app

App exchanges PoP JWT against AS2, shows PoP

AS2 returns
token(s) to app

Step 5 in the 3rd party sequence implies a federated trust model - the SaaS AS2 must be able to trust & validate the JWT issued by the enterprise AS1.

The above model is attractive for the symmetry it provides between both application categories.

5 comments:

maybe you can link me to the WG discussion about it if I missed it but what are the risks linked to the following sequence?1- app requests token to TA2- TA contacts AS to get one3- TA hands over the token to the app.

in a authentication only scenario (no authz AT ALL) why not have the TA handing over the same token to several apps?(i'm also in a scenario with no Refresh token)

Bertrand, the risk is that an attacker can lay claim to the custom URL scheme (or more generally impersonate) of the valid app and the TA would pass the token to that attacker. Passing the code instead, and having the app show knowledge of that code when it exchanges it for the tokens at the AS mitigates this risk.

if the tokens carry no authz, then sharing them across apps would be less of an issue. Though it could create a privacy issue of correlation in a consumer scenario

The TA checking the signature of the app only protects the request. The response might go to any app that has registered the same URI scheme. PKCE protects the response. The TA should still be verifying the signature of the app.

This is the flow I was talking about http://www.thread-safe.com/2015/01/napps-high-level-flow-for-ios.html