OAuth 2.0 redirection with Universal Links should NOT require user interaction

Originator:konstantin.lapine
Number:rdar://51091611 Date Originated:May 23 2019, 6:43 PM
Status: Resolved:
Product:iOS + SDK Product Version:iOS 11+
Classification:UI/Usability Reproducible:Always
 
Area:
Foundation

Summary:
Utilizing claimed "https" scheme redirection is the only reliable generic way of identifying a native OAuth 2.0 client. In iOS, Universal Links should NOT require user interaction when used for redirection flows in the ever popular delegation protocol.
---
The best current practices for OAuth 2.0 implementation in Native Applications are outlined in RFC8252 and recommend:
- External user-agents should be used for authorization requests. Safari and the in-app browser tabs—SFSafariViewController, SFAuthenticationSession, and ASWebAuthenticationSession—can be used in iOS.
- In order to prevent client impersonation, the (public) client software needs to be identified with means other than a client secret: 
1. The user could verify the client information and provide their consent for client authorization
2. Claimed "https" scheme could be used in the redirection URI

The consent screen relies on user's input; hence, it may not guarantee client identification, allowing for mistakes. In addition, the consent screen cannot be implemented consistently in iOS. The authentication classes impose a mandatory consent dialog that lacks client identifier, showing only the app's (product) name. Hence, a separate consent screen is required from the authorization server in all cases. When the authentication classes are used for authorization, the user will be asked for their consent an extra time. A redundant user interaction, especially on mobile, deteriorates the user experience. 

Claimed "https" scheme redirection URI could serve as a client identifier and should NOT require additional user input. This, however, cannot be achieved with the current implementation of Universal Links. If the external user-agent is initiated/opened with the authorization URL, redirecting to a Universal Link from the authorization endpoint does not open the associated app. An extra, intermediate screen is required, from which the authorization request has to be made. In iOS 11+, with the in-app browser tabs, the user has to initiate the authorization request in order for a Universal Link to be redirected to the app. The  request can be made automatically in Safari, but an intermediate screen is still required. Also, using Safari requires leaving the app. In iOS 10, Universal Links are not redirected to the app.

Steps to Reproduce:
Initiate an external user-agent with an OAuth 2.0 authorization URL (RFC6749, section-4.1.1). Provide a Universal Link as the `redirect_uri` parameter. Do not introduce any additional screens, like a consent dialog from the authorization server, and take the user directly to the authorization endpoint. 

An example template app:
https://github.com/lapinek/oauth-2-universal-links

Expected Results:
Redirecting to a Universal Link opens the app

Actual Results:
The Universal Link is opened in the user-agent

Version/Build:
iPhone 6s: iOS 11.4.1 (15G77)
Xcode 10.2.1 (10E1001): iOS 10.3.1 (14E8301), iOS 11.4 (15F79), iOS 12.2 (16E226)

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!