I'm trying to implement an OAuth2 authorization code flow as part of my iOS app. I open the third party's OAuth2 login page in an SFSafariViewController, and the url that I pass to the Safari controller includes an https redirect uri that is a universal link. When the user hasn't done an OAuth2 login recently, the Safari controller displays the login page, the user presses the "log in" button, and then the redirect uri is followed as a universal link, bringing control back to the app, as expected. (The user doesn't enter credentials on the third party's page because Safari has already cached them.)
The problem is that, if I immediately try to repeat that process, the Safari controller does not appear to open the third party's login page, and, judging by the hostname displayed at the top of the screen, it tries to go straight to the redirect uri, which doesn't get treated as a universal link this time. The Safari controller just shows a 403 error because the uri doesn't correspond to any real webpage.
Does anyone know the cause of and/or the solution to this problem? I suspect that it may have to do with this behavior documented by Apple (https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html):
If you instantiate a SFSafariViewController, WKWebView, or UIWebView object to handle a universal link, iOS opens your website in Safari instead of opening your app. However, if the user taps a universal link from within an embedded SFSafariViewController, WKWebView, or UIWebView object, iOS opens your app.
That doesn't entirely explain why it works in the first case but not in the second, and it doesn't explain how I might prevent the second case from happening.