Description
My case has only been tested with Android-compliant native URIs.
Android allows apps to define custom urls in the form of fakeprotocol://normaluri as their own to easily redirect from browsers to native apps.
OAuth2's RFC8252 specifies in Section 4 that:
For authorizing users in native apps, the best current practice is to
perform the OAuth authorization request in an external user-agent
(typically the browser) rather than an embedded user-agent (such as
one implemented with web-views).
This, following Section 7 can be achieved in three ways:
- Claimed "https" Scheme URI Redirection (Section 7.2)
This is an issue because on recent versions of Android the system will try to open any app that may support the url scheme, unless the developer pays for a webserver and implements Android's website association which ensures the app will be verified as "official" by the system and will be launched automatically when receiving a browser redirect.
This may still not happen if the user decides to not launch the app and stay in the browser.
This solution is expensive for the developer and requires a considerable amount of effort for a single-time event.
- Loopback Interface Redirection (Section 7.3https://tools.ietf.org/html/rfc8252#section-7.3))
This solves the cost problems of the issue mentioned above but opens a lot of security related issues, since every service will be able to access the local webserver and send (junk) data to it, or the port may be occupied by another running service, plus, this requires either the implementation of a webserver through a third party library, which increases the app size unnecessarily or through native APIs, which are known to be generally insecure and should be avoided due to their simplicity (plus, this can be much less secure than the discouraged WebView implementation).
- Private-Use URI Scheme Redirection (Section 7.1)
Android lets app define custom URIs (for example market://detail?id=com.discord opens the Play Store at Discord's app page) and following the Deep Linking Android documentation the browser will have no choice other than to open the app unless more than one app handles the URI. This can easily be avoided by using standard practices such as using the package name as the URI's scheme (discord:// or com.example.app:// as explained in current Section's documentation).
As this Section specifies, the system (Android) will handle the request and launch the appropriate app once the OAuth2 server (Discord) redirects to the callback URI.
The issue is Discord does not allow to specify any URI that is not a valid website/web server URL (begins with http:// or https:// and has at least one period in it I believe is the minimal requirement). This forces Android developers that want to integrate Discord related features (bot management interface, "playing ..." status when in game, etc) to either pay for an online server that only manages logins, which happen once per app installation or resort to insecure or discouraged practises.
It would therefore be appreciated if Discord supported native URIs, as specified by RFC8252 Section 7.1 to allow a secure, guaranteed and official way to authenticate a user using the default WebBrowser (or Chrome Custom Tabs to ensure a seamless transaction between the app and the Discord login/authorization page).