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
- 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:
hello,
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 TA
2- TA contacts AS to get one
3- 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
Thanks
Paul
Hi Paul,
thanks for that answer.
about "having the app show knowledge of that code", if I'm an attacker, I can show knowledge of that code since I just stole it anyway. am I missing something?
my mitigation option here was that the TA could verify the signature of the app package.
and again, I'm biased by my current use cases : local native apps only. (and I'm looking for simpler implementation options like "Ressource Owner Password Credentials" profile in Oauth for instance.)
Hi bertrand, yes I mispoke.
I should have said
'Passing the code instead, and having the app show knowledge of *a secret* when it exchanges it for the tokens'
So, even if an attacker can steal the code, it wont have the secret associated with the valid app, and so wont be able to exchange the code for the token(s).
Now, for native apps, the current reality (given how they are publicly distributed etc) is that they may not have a client secret.
The SPOP (https://tools.ietf.org/html/draft-ietf-oauth-spop-00) mechanism gets around this, allowing the client to demonstrate knowledge of an ephemeral secret.
Having the TA verify the signature of the requesting app protects against a malicious app requesting a code of the TA, but not a malicious app intercepting the response.
thanks
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
John B.
Post a Comment