Promote Universal Links as the means of validating OAuth 2.0 client identity in iOS

Are you filing an issue about iOS 12?
No, although it affects iOS 11-12.

Is your feature request related to a problem? Please describe.
It is not an AppAuth-iOS specific problem, but one, I think, you should be concerned about—as the provider of a leading OAuth 2 mobile solution.

The library follows the best current practices outlined in RFC8252. The RFC suggests two alternatives not relying on a client secret to prevent Client Impersonation: a mandatory client authorization consent screen from the authorization server or a claimed “https” scheme redirection URI. It is not what the library can implement on its own, but something you may want to provide input on.

Please consider, that asking user for a consent is not a reliable way of identifying a client, because it relies on user attentiveness. Less importantly, in iOS, such consent dialog cannot be implemented in a consistent and user friendly way, because when the authentication classes are used, they impose their own alerts, which, by the way, don't help with the client identification.

Hence, using claimed “https” scheme redirection seems to be the generic way to ensure client identity. The claimed “https” scheme URLs are realized in iOS as Universal Links. In their current implementation, Universal Links are not suited for OAuth 2.0 redirection flows because they require an intermediate screen, from which the authorization request needs to be initiated. In the case of the in-app browser tabs, the user has to initiate this request. (In Safari, automatic redirection to the authorization endpoint or navigating to it with JavaScript seems to be working, but an intermediate screen is still needed.)

This implies that, for a “third-party” client app, both the consent dialog and Universal Links have to be employed.

Describe the solution you’d like

1. The library docs should emphasize the importance of Universal Links and provide example(s) of their implementation.
2. Because a mobile OAuth 2.0 client cannot maintain a secret, ultimately, the client identification has to be implemented on the system level; hence, it needs to be supported by Apple. If you agree that the end user interaction should not be needed for redirecting Universal Links to the associated app, specifically, with the authentication classes that are not purposed for general browsing and designed to take the user back to the app, please help to convey that message to Apple. I am sure your opinion will weigh in more than my personal one: https://openradar.appspot.com/51091611. If they follow, Universal Links will become more reliable and user-friendly OAuth 2.0 redirection technique in native environment; secure, they already are.

Describe alternatives you’ve considered
With regard to OAuth 2.0 in iOS, there is no good alternative to claimed “https” scheme redirection at the moment. A (consent) screen from the authorization server followed by redirecting to a Universal Link can prevent client impersonation, but it raises usability concerns.

Dynamic client registration may allow for creating a confidential native client. However, it is reasonable to expect such clients to be limited in rights and/or obligated to show a mandatory consent screen—which we are trying to avoid. It seems, providing the authorization server with means of verifying the registering party, like software statement assertion, would bring us back to maintaining distributed secrets in public clients. In addition, maintaining quantity of clients that is equal or exceeding number of mobile users would introduce extra maintenance efforts on the authorization server side.

(Theoretically, Apple could re-use Universal Links app/site association in allowing the authentication classes to handle “https” callbacks. This, however, would take action further away from the system level, require full URI passed in, and, therefore, seem less of a “universal” approach. And, it could require changes in the existing implementations.)

Additional context
A video, using a Google OAuth 2 web application client.
A testing template on GitHub.

Start by reviewing RFC 8252 section 8.6 and the linked OAuth 2 Universal Links testing template. The issue asks for library documentation emphasizing Universal Links with examples, plus advocacy to Apple; done means the documentation request is addressed and any external-response scope is clearly separated.