We have an iOS app, and we have set up deeplinking via an apple-app-site-association.json. This makes that when I open our link in Google the iOS app is opened. Great.
Fast forward and we're implementing OpenID Connect. This means that we redirect you to an identity provider, you're authenticated, and you're redirected back to our website. At this point - redirecting from identity provider to website - iOS detects this and tries to open the url in our iOS app. This won't work as the app cannot exchange the authorization token for a token set1.
That is solvable; I have excluded the return url in the website from deeplinking, and this works as expected. Except that the app is still opened. I discovered that when I go back to the browser, I am authenticated inside our website.
My hypothesis is that, after exchanging the authorization token for a token set, the website redirects you back to the page within the website where the OpenID Connect process was started2, iOS intercepts the request and decides to open the app. Reason being that I go from domain A to a non-exluded url on domain B without interaction and as such the exclusion is ignored.
Two questions:
- Does anyone have documentation about the conditions that trigger the app to be opened? I scoured the internet, but could not find a comprehensive list.
- Is there a way to prevent this behavior?
We are currently bypassing this behavior by not performing a redirect based on a Location header, but by showing a success page (on the deeplink excluded url) and performing a redirect using a meta refresh tag in the html. This is not the desired solution, and I would love to have a better one.
1: The mobile app is a different client from an OpenID Connect perspective
2: Within OpenID Connect you need to explicitly declare the urls that the user is allowed to be redirected to from the identity provider without wildcards. That's why we have a single entrypoint and we redirect you to your final destination within the website.