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

[Kosuke Koiwai]

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
>
>