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

[William Denniss]

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> 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 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
> 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/cf5efe65/attachment.html>