<div dir="ltr">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.<div><br></div><div>FYI, this feature in Android is called <a href="http://developer.android.com/preview/features/app-linking.html" target="_blank">App Links</a>, and is a part of the M platform. On pre-M devices the pattern should still work, but an intent disambiguator would be shown.<br></div><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 7:43 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>On the Call:</div><div>John Bradley</div>William Dennis<div>Brian Campbell</div><div>Paul Madsen<br><div><br><div>We discussed the new features being released in iOS9 and Android.</div><div><br></div><div>Apple’s <a href="https://developer.apple.com/library/safari/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html" style="text-decoration:none" target="_blank"><span style="font-size:14.666666666666666px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">SFSafariViewController</span></a><span> and Android’s </span><span><span style="text-decoration:underline;font-size:14.666666666666666px;font-family:Arial;color:rgb(17,85,204);vertical-align:baseline;white-space:pre-wrap"><a href="https://developer.chrome.com/multidevice/android/customtabs" style="text-decoration:none" target="_blank">Chrome Custom Tabs</a></span></span>  allow us to use the regular OAuth/Connect code flow to the enterprise or a SAAS.</div><div>SAAS can chain existing federation protocols to enterprises to achieve SSO based on session information in the browser.</div><div><br></div><div>Apple’s <a href="https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10" target="_blank">Universal Links</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>The feeling was that these changes will allow us to do SSO for native apps without requiring as many changes to the existing protocols.</div><div><br></div><div>The recommendation on the call was to focus the main document as a best practices guide for doing Native SSO.</div><div><br></div><div>We still need a spec to cover session/device termination from a enterprise to a SAAS.  (SLO) </div><div>We need to document best practices for tenant  discovery using <a href="http://accountchooser.com" target="_blank">accountchooser.com</a> or native methods like app restrictions on Android.</div><div>We need to cover how to use PKCE for the flows to prevent token theft.</div><div><br></div><div>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.</div><div><br></div><div>John B.</div><div>
<br></div></div></div></div><br>_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
<br></blockquote></div><br></div>