[Openid-specs-ab] AppAuth: Anyone having issue with redirect back to apps?

[Joseph Heenan]

Hi Kosuke

For iOS, probably the next thing I would try is to gather sysdiagnose from a device that has had the issue recently:

https://download.developer.apple.com/iOS/iOS_Logs/sysdiagnose_Logging_Instructions.pdf

This may reveal something about why the link association has failed to establish.

Thanks

Joseph

> On 12 Jun 2023, at 13:29, Kosuke Koiwai <kkoiwai at gmail.com> wrote:
> 
> Hi Joseph,
> 
> Thanks for the tip!
> 
> Yes it is much less than 10% but still not negligible considering the user base.
> We force-call Chrome so third party browsers shouldn't be the cause.
> Don't see any trend regarding OS/browser versions, device makes, etc.
> (except, a certain Chrome&Android version had a bug in past handling
> app links from CustomTabs.)
> The deeplinks are called from a different subdomain.
> Our users are mostly in Japan and the AAPA/assetinks files are intact,
> I checked with the CDN (i.e.
> https://app-site-association.cdn-apple.com/a/v1/yourdomain.com).
> but I acknowledge that there might be an issue at the client side.
> 
> Usually the issue recovers after re-installation of the app, device
> restart or a few hours of wait, but in a rare case these remedies
> don't work.
> 
> Kosuke
> 
> On Mon, Jun 12, 2023 at 7:14 PM Joseph Heenan <joseph at authlete.com> wrote:
>> 
>> Hi Kosuke
>> 
>> I presume it’s still a relatively small number of user (<10%)?
>> 
>> I do work with customers that occasionally see issues like this, but quite often a bit of data is necessary to narrow down the issue.
>> 
>> Problems I have seen in the past:
>> 
>> Custom URL schemes fail on <2% of Android devices, with Samsung browser being a common theme (solution: use claimed https urls)
>> Deeplinking fails to establish if the .well-known/apple-app-site-association is geoblocked in a way that prevents it being fetched for some clients (the fetch for this file usually comes from Apple’s servers from a region intended to be close to the region the user is believed to be in, not from the user’s device - solution: don’t geoblock trivial config files)
>> Deep linking is, at best, unreliable if the deep link is launched from a web page on the same hostname (solution: put the redirect uris on different hostnames/domains from the AS)
>> Deep linking is, at best, unreliable if the deep link is launched from somewhere that is not a direct result of a user action (so e.g. a top level redirect is okay, a link the user clicks on is ok, but assigning to window.location in the result handler for a xmlhttprequest is getting dodgier)
>> 
>> 
>> And probably others that I don’t immediately remember :)
>> 
>> My usual approach (after checking for some of the standard things) is to start gathering some data - if you know that it’s certain OS versions, certain browsers, certain locations, that gives you something to investigate.
>> 
>> Thanks
>> 
>> Joseph
>> 
>> 
>> On 12 Jun 2023, at 03:52, Kosuke Koiwai via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>> 
>> Hi all,
>> 
>> I'm having an issue that not a negligible number of users can't
>> redirect back to native (Android/iOS) apps after OIDC login sessions
>> on ChromeCustomTab/ASWebAuthenticationSession.
>> Most users can successfully login, but some fraction of users can't,
>> and I have not been able to reproduce the issue.
>> 
>> Occurs with both HTTP schema (AppLinks/Universal Links) and custom URL schema.
>> I'm wondering if anyone has the same issue.
>> 
>> Thanks,
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230613/43739afb/attachment.html>