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

[lapinek]

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.

[WilliamDenniss]

Regarding point 1, I'm definitely supportive. If you wish to make a contribution that enhances the documentation and samples for Universal Links, that would be great.

Regarding point 2, to summarize the FR, you're asking for Universal Links to be opened in the app even if the user doesn't tap the link. Personally I support this as it would enable some additional patterns that don't work today, however I suspect there may be some reasons for this OS behavior. While it's good to propose improvements for consideration by the platform vendor, AppAuth needs to work with the limitations presented to us, and I don't personally have a way to advance your proposal. One workaround is that the owner of the universal link needs to render a link to cover the case where the page was rendered rather than the universal link triggered.

[lapinek]

Just a couple of comments for now. I am not sure what would be a good reason for extra user interaction in the case of an authentication class, which, according to the docs,

. . . manages sharing a one-time login between Safari and an app, which can also be used for automatic login for associated apps

The workaround you suggested will not work from the same domain. The static content (with the failed link) would need to be maintained separately, which is, obviously, less than ideal. From the docs:

When a user is browsing your website in Safari and they tap a universal link to a URL in the same domain as the current webpage, iOS respects the user’s most likely intent and opens the link in Safari. If the user taps a universal link to a URL in a different domain, iOS opens the link in your app.

Which, again, brings up the question why does it apply to the authentication classes—not meant for casual browsing?

A demo: https://forgerock.wistia.com/medias/x12g95gkm3

So, even if this fallback was implemented, an intermediate (consent) screen presented by the authorization server directly in front of the authorization endpoint would still be a better option.