[Openid-specs-native-apps] June 23 Notes from NAAPS call

Wed Jun 24 23:25:56 UTC 2015

Some of the design assumptions we were making about the native TA may also no longer hold true.

1 That the interprocess communication between the TA and the app is insecure (perhaps not with App Links)
2 That the client app needs it’s own refresh token to avoid app flips for AT (perhaps still true)

In the browser model 2 is satisfied without changing OAuth grants.

If you use a app link to invoke a native TA that solves one thing we have not been able to find a solution for to this point, TA impersonation for phishing.  
If the app invokes a https URI it will go to the the AS on the web or the legitimate TA.

One possibility for a native TA without changing OAuth too much would be to have the TA use the authorization endpoint with a prompt=none for getting codes and maintaining the state in the browser tab.   A AS supporting a native TA would auto register there TA redirect_uri for apps allowed to use the TA.  

A native app makes a OAuth request to a https: URI, one of two things happen.

1 There is no TA and the request goes to the Web AS as normal via the browser tab.
2 There is a TA that has claimed the AS URI, the browser tab invokes the TA that claimed the URI, the TA then checks whatever device state etc it needs to,  it then makes the call to the AS (may need a different authorization endpoint to avoid the claimed one) as the original client_id but with it self as a claimed redirrect_uri.  The TA gets the response and returns it to the app via the apps claimed uri.

That could work with the existing Connect using only a bit of server side logic around redirect_uri.

However I think that developers are probably going to favour just using the web server as the TA directly, as it likely saves some app flips and is probably easier to code as the client app is not swapped out and re-invoked.

I agree with William that it may be possible to transparently insert a native TA.

The question is what are the compelling reasons to do it and are they worth the potential confusion generated by having multiple ways to do the same thing, from the apps point of view?

We do need to look at some of the detail around claimed URI.  I don’t know that they are 100% safe.  It may still be possible for a app to invoke the traditional web view and capture the redirect somehow.  That needs to be checked if we are going to use that mechanism to determine if apps are legitimate.

John B.

> On Jun 24, 2015, at 7:39 PM, William Denniss <wdenniss at google.com> wrote:
> 
> This is something John and I discussed offline previously, but I think it's worth mentioning here in the context of not moving forward with some of the native TA aspects of NAPPS:  If people are interested in handling part of the auth request natively, theoretically the TA could register a universal link for the auth request, and inject themselves into the flow that way. As it's all using HTTPS URLs, and the app<->domain association is guaranteed by the OS, this is also fairly safe.  A lot safer in fact than the custom-URI scheme model for TAs, where someone could hijack the TA's URI scheme and phish / MitM the user.
> 
> FYI, this feature in Android is called App Links <http://developer.android.com/preview/features/app-linking.html>, and is a part of the M platform. On pre-M devices the pattern should still work, but an intent disambiguator would be shown.
> 
> One benefit of the native TA we had discussed, was as a place to perform lightweight-MDM operations such as enforcing device policy (e.g. presence of lockscreen).  There is a way to achieve this without a native TA I believe:
> 
> An important piece of session management is assigning a virtual device identifier to the device authentication context, and to have this identifier associated with OAuth tokens generated from that context. This allows all tokens for a device to be revoked or suspended at once, and for the IdP to have a better overview of the user's devices.  These virtual device identifiers can also be used to associate device policy signals, e.g. you could have a trusted app that reports these signals, which are then associated with the device identifier and any enforcement logic applied to all tokens connected through the identifier.
> 
> A huge benefit I see to bringing the web OAuth pattern to native apps is being able to re-use all the web infrastructure, not to mention supporting non-OAuth auth flows too.  In past discussions it was generally assumed that a native TA would need a fallback web TA anyway (unless you control the environment and can force every user to install the native TA). By making the fallback the primary method (with some enhancements), we can have one solution that works everywhere: desktop & mobile web, iOS, Android, and other platforms that also support this "browser-view" model.  Many SaaS apps are web-views today for OAuth, so we should document the best practices for doing this using browser-views (SafariViewController, Chrome Custom Tab), and encourage them to adopt that pattern instead.
> 
> 
> On Wed, Jun 24, 2015 at 7:43 AM, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
> On the Call:
> John Bradley
> William Dennis
> Brian Campbell
> Paul Madsen
> 
> We discussed the new features being released in iOS9 and Android.
> 
> Apple’s SFSafariViewController <https://developer.apple.com/library/safari/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html> and Android’s Chrome Custom Tabs <https://developer.chrome.com/multidevice/android/customtabs>  allow us to use the regular OAuth/Connect code flow to the enterprise or a SAAS.
> SAAS can chain existing federation protocols to enterprises to achieve SSO based on session information in the browser.
> 
> Apple’s Universal Links <https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10> and similar functionality on Android, AS will be able to better guarantee that redirect_uri are returning codes to a legitimate instance of an app.
> 
> ACDC will be useful in some use cases, but is no longer required for NAPPS if we are not using a native app with a refresh token to maintain state.
> 
> The feeling was that these changes will allow us to do SSO for native apps without requiring as many changes to the existing protocols.
> 
> The recommendation on the call was to focus the main document as a best practices guide for doing Native SSO.
> 
> We still need a spec to cover session/device termination from a enterprise to a SAAS.  (SLO) 
> We need to document best practices for tenant  discovery using accountchooser.com <http://accountchooser.com/> or native methods like app restrictions on Android.
> We need to cover how to use PKCE for the flows to prevent token theft.
> 
> The question for the group is if there is a strong desire to proceed with the original plan to extend OAuth/Connect enable a native TA.
> 
> John B.
> 
> 
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net <mailto:Openid-specs-native-apps at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps <http://lists.openid.net/mailman/listinfo/openid-specs-native-apps>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20150624/bb2ca634/attachment-0001.html>