iOS - Login with deep links or Passkeys do not work when used in OAuth 2.0 flow

[UBaggeler]

Steps to reproduce

1. Server: Configure OAuth 2.0 client under "Administration" > "Security" with provider that uses deep links (custom url scheme or universal links) or Passkeys in their login flow
2. iOS App: Start login, go to OAuth 2.0 provider
3. Try to tap on link with deep link (e.g. "superloginapp://") or use Passkeys

Expected behaviour

App should allow to do deep links or use Passkeys

Actual behaviour

Login view (WKWebview) does not handle deep links or Passkeys. These are restrictions of WKWebViews (which are not recommended for login flows)

Reasoning or why should it be changed/implemented?

Environment data

iOS version: any (tested on iOS 26.2)

Nextcloud iOS app version: 7.2.2 / master-branch

Nextcloud version: independent

[UBaggeler]

From looking at the history it seems that around 6.4.0 (#3303) the in-app browser (using SFSafariViewController) and external system browser was removed and replaced in favor of an internal WKWebView. Looking at the PR and the issues, it is not clear why this change was introduced. My guess is (from interpreting release notes) that there were issues cookies, that did not get cleared (as SFSafariViewController and the system browser do not allow to clear cookies).
Also it seems that Android is (still) opening the system browser.

Using WKWebView comes with limitations (handling of deep-links, Passkeys among other things) and it is generally advisable to not use (embedded) WKWebViews for logins on iOS (also from security perspective).
With Apple's introduction of ASWebAuthenticationSession (backed by SFSafariViewController) it is also possible to start ephemeral sessions with an empty cookie store.

@mpivchev @marinofaggiana What was the reason to revert back to WKWebViews after introducing in-app browser and system browser login options before?

[mpivchev]

#3996