<div dir="ltr">In the case of Chrome Custom Tabs on Android, the app can look at the URLs that the user loads. If they see a URI matching their redirect-URI they can get the token, and close the tab. This is nice in the sense that it's quite easy to implement, though it means the app can log every URL param (so sensitive tokens within the custom tab should probably be passed using POST). <a href="https://developer.chrome.com/multidevice/android/customtabs" target="_blank">Docs</a>. <a href="https://github.com/GoogleChrome/custom-tabs-client" target="_blank">Sample code</a>. The API is: `void onUserNavigationStarted(String url, Bundle extras);`<br style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6000003814697px;line-height:1.45"><div><br></div><div>iOS 9 on the other hand doesn't have any new way for the app to communicate with the SafariViewController. In the WWDC video they suggest using Custom URI schemes (what we <a href="http://wdenniss.com/rfc/draft-wdenniss-customuri-01.html" target="_blank">already do</a> for OAuth using the system browser). I suspect (though am yet to confirm) that their Universal Links will work too, meaning if the SafariViewController loads a HTTPS redirect that the app has claimed – the app will get it. Both approaches actually work regardless of whether the user is in the SafariViewController or Safari itself (which is good because the user can actually open safari from the SafariViewController), and in the case of Custom URI schemes provides a nice fallback using the system browser for iOS 8 and below. <a href="https://developer.apple.com/videos/wwdc/2015/?id=504" target="_blank">Video</a> <a href="http://asciiwwdc.com/2015/sessions/504" target="_blank">Transcript</a> skip to 23:09 for the OAuth bits.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 15, 2015 at 4:02 PM, 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">I suspect that the callback URI for the app would look like a regular https: URI. <div><br></div><div>The callback/claimed URI is a separate feature from the browser tab. It would be generic to the browser. Letting apps claim links that would otherwise go to a web server.</div><div><br></div><div>So a linked in link in a email would open the native app rather than the web page.</div><div><br></div><div>We don’t have much info on how they would work together.</div><div><br></div><div><br></div><div>Assuming the call to a token agent, and the call to the web site is the same then a AS could just insert a token agent by having the user install a app.</div><div><div class="h5"><div><br></div><div><br><div><blockquote type="cite"><div>On Jun 15, 2015, at 7:50 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:</div><br><div><div dir="ltr">What I am still vague on is that how the callback from the browser tab works. <div><div>(Please provide me with a documentation/video links if there is one.)<br></div></div><div><br></div><div>Does a regular OAuth callback work? </div><div>In which case, what redirect_uri it should use? </div><div><br></div><div>Nat</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-16 6:56 GMT+09:00 William Denniss <span dir="ltr"><<a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>URL claiming is definitely a huge advancement, finally we can get some assurances of the identity of the app receiving the token (and not just that the token went back to the requesting app which PKCE ensures). In Android, <a href="http://developer.android.com/preview/features/app-linking.html" target="_blank">Apps Links</a> are a platform feature, so the rollout will take longer. Chrome Custom Tabs however will soon be <a href="https://support.google.com/chrome/answer/2393487?hl=en" target="_blank">available</a> on devices back to Android 4.1+ (Jelly Bean). Both these features start to bring the native app and mobile web experiences closer together.</div></div><div><br></div>It does look like it will be possible to basically insert a native TA into the process, simply by claiming the the auth URL. Given this, I believe we can write a spec for doing OAuth on Mobile without needing to spend a lot of time on the Native TA part.<div><br></div><div>Starting in 'seed 2' of iOS 9 (not yet available), the app association file (required for Universal Links) will no longer need to be signed using the same key as the SSL certificate which will make this a lot more accessible for developers.<br><div><br></div><div>One thing to note is that SFSafariViewController is still in beta, and they are explicitly seeking feedback. So if we think something is missing now is the time to ask for it.</div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 15, 2015 at 2:21 PM, 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">In principal closing the tab with a universal link could act as a replacement for validating the app bundle_id effectively the same way the https redirect URI validates the identity of a web server.<div><br></div><div><br></div><div>That might be logically simpler than trying to validate and track bundle_id and signer. </div><div><br></div><div>We need to see if it works in practice.</div><div><br></div><div>This is sort of the same thing Google is doing in smart lock so that a native app and website can share the same password info.</div><div><br></div><div>John B.</div><div><div><div><br></div><div><br></div><div><div><blockquote type="cite"><div>On Jun 15, 2015, at 12:34 PM, David Waite <<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">WebKit controls allow you to hook into events and inject javascript, but as a consequence you are running with a separate copy of user state.<div><br></div><div>The new control is effectively a Safari tab which pops up over your UI. I don’t believe you can do too much more than tell it what page to start at, or programmatically dismiss it. But, it is supposed to have all the state and credential access of the system browser. Among other things, you cannot control what browser controls are visible to the user, which include a non-editable address bar and a dismissal button.</div><div><br></div><div>This does not provide new functionality, but could substantially improve the UX. The user gets a modal popup rather than bouncing to/from the system browser, and has a button to cancel/dismiss and be returned exactly where they started. The user also doesn’t wind up with additional MobileSafari tabs left behind by the authentication process.</div><div><br></div><div>Apple explicitly called this out as useful for OAuth in their presentation. They proposed the use of custom URLs to close it, however I wonder if universal links (also new in ios 9) would work and be a better option.</div><div><br></div><div>Universal links allow your website to give permission for one or more apps to be used to service particular resource paths. These apps have to be provisioned with the domains which they are willing to service (so no universal TA).</div><div><br></div><div>On requesting the URL, the system will skip safari and transition directly to your app. There appears to be an interface to return back to the originating app as well, as if the new app was a new card on top of the navigation view stack.</div><div><br></div><div>This allows you to control a single app to be called on use of a URL, a single ownership semantic Apple is unwilling to provide on iOS. It also allows for a fallback - if the app isn’t installed, the user is sent to the page in Safari. From there, you could use app banners to advertise the token agent app as a better experience.</div><div><br></div><div>It remains to be seen through experimentation if these work well or if they work well together. But it may be we got a way to invoke a TA and automatically fall back to an in-place web view if it isn’t installed, a better UX overall, and that we got a way to more securely redirect back to the app when finished.</div><div><br></div><div>-DW</div><div><br><div><blockquote type="cite"><div>On Jun 15, 2015, at 7:08 AM, Mike Varley <<a href="mailto:mike.varley@securekey.com" target="_blank">mike.varley@securekey.com</a>> wrote:</div><br><div>
<div style="word-wrap:break-word">
Right - from what I understand the new tabs do everything the system browser does, and allows access to system browser state. But I only know what I saw from the keynote :)
<div><br>
</div>
<div>So improved UX, not only from a buttons and tabs perspective, but the user's state is now accessible from the system browsers as well. </div>
<div><br>
</div>
<div>MV<br>
<div><br>
</div>
<div>
<div>
<div>On Jun 15, 2015, at 8:50 AM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">hey Mike, if true, you are saying the new tabs can 'do everything the system browser does', so the only difference is UX<br>
<br>
Im not diminishing the importance of the UX , just want to understand what we gain<br>
<br>
<div>On 6/15/15 8:36 AM, Mike Varley wrote:<br>
</div>
<blockquote type="cite">
I seem to recall that both iOS and Android will now allow these embedded web views (i.e., chrome tabs and safari web views) full access to the user's settings: including cookies, stored passwords, local storage, (device certificates as John mentioned), touchID?
the works. And there is the improved UI experience as well, that you pointed out, with "back' buttons that automatically return the user to the calling App.
<div><br>
</div>
<div>MV<br>
<div><br>
</div>
<div><br>
</div>
<div> <br>
<div>
<div>On Jun 15, 2015, at 8:05 AM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com" target="_blank">paul.madsen@gmail.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">John, can you expand on<br>
<br>
'However it seems like we will be able to do significantly more with the browser than we had been thinking.'<br>
<br>
As I see it, the new feature doesn't enable anything *more* other than a better UX on iOS? True?<br>
<br>
Paul<br>
<br>
<div>On 6/12/15 4:38 PM, John Bradley wrote:<br>
</div>
<blockquote type="cite">
Have a look at 23min into this video from ADC.<br>
<div>
<div>
<div><br>
</div>
<div><a href="https://developer.apple.com/videos/wwdc/2015/?id=504" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://developer.apple.com/videos/wwdc/2015/?id=504</a></div>
</div>
</div>
<br>
<div>This is a significant development.</div>
<div><br>
</div>
<div>In talking to others from Google yesterday and today, they have introduced similar functionality in Android rolling out in approximately the same timeframe, and backwards compatible with current versions of Android.</div>
<div><br>
</div>
<div>Being able to invoke a web tab without an app flip is a significant change, potentially making the TA in the browser that we have talked about the preferred option on iOS.</div>
<div><br>
</div>
<div>People should look at the ACDC draft <a href="https://bitbucket.org/openid/napps/wiki/Home" target="_blank">https://bitbucket.org/openid/napps/wiki/Home</a>.</div>
<div><br>
</div>
<div>It may be that NAPPS for enterprise is OAuth using a tab plus PKCE and some additional app verification logic + fido api in the browser.</div>
<div>For SasS we may be able to use OAuth + ACDC and discovery in a tab.</div>
<div><br>
</div>
<div>It looks like the tab will have access to device certificates solving some peoples issues around that.</div>
<div><br>
</div>
<div>We should also be able to do <a href="http://accountchooser.com/" target="_blank">
accountchooser.com</a> in the browser tab to perform account discovery.</div>
<div><br>
</div>
<div>Now that the changes have landed on iOS and Android we should be good to do testing in the late summer fall.</div>
<div><br>
</div>
<div>Please start the discussion on the list.</div>
<div><br>
</div>
<div>I recognize that some people will still have use cases for native token agents, so I am not proposing completely eliminating that yet.</div>
<div><br>
</div>
<div>However it seems like we will be able to do significantly more with the browser than we had been thinking.</div>
<div><br>
</div>
<div>Regards</div>
<div>John B.</div>
<div><br>
</div>
<br>
<fieldset></fieldset> <br>
<pre>_______________________________________________
Openid-specs-native-apps mailing list
<a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________<br>Openid-specs-native-apps mailing list<br><a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>Openid-specs-native-apps mailing list<br><a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">Openid-specs-native-apps@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br></div></blockquote></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" target="_blank">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>
</div></div><br>_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a href="mailto:Openid-specs-native-apps@lists.openid.net" target="_blank">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><br clear="all"><div><br></div>-- <br><div>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div>
</div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>