Motivated by T410521: Add com.blogspot.wikikamus: to list of allowed OAuth2 URI schemes.

Change #1217825 had a related patch set uploaded (by Chuiimuii_ofc; author: Chuiimuii_ofc):

[mediawiki/extensions/OAuth@master] Allow OAuth callback URLs with custom protocols without modifying \

https://gerrit.wikimedia.org/r/1217825

I was wondering if there is a already a timeline for this. :)

This feature is needed for native apps like the Android Commons App as well as the iOS i am developing https://commons.wikimedia.org/wiki/CommonsFinder_iOS_App (a mobile iOS app for Commons).
To be able to register with custom uri schemes, became even more critical due to the recent rate-limit changes, since non-OAuth2-authenticated requests are not getting increased rate limits.

Not being able to use OAuth2 for user authentication is a blocker right now to release the app to a wider audience in the app store.

In response to https://commons.wikimedia.org/w/index.php?title=Commons_talk:Mobile_app&section=8#OAuth_support I wanted to mention that this is still relevant to even start using OAuth2 in native clients. Here is a sample screenshot what happens when trying to register for a native consumer with a custom uri scheme.

(cross-referencing: T426614: add "CommonsFinder://" custom scheme to $wgUrlProtocols for native app OAuth2 support)

Change #1288997 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] UrlUtils: Add an option to allow any URL protocol

https://gerrit.wikimedia.org/r/1288997

Change #1288998 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/OAuth@master] Allow any URL protocol for OAuth app callback URLs

https://gerrit.wikimedia.org/r/1288998

An evil app can trick the user into associating it with the same scheme a good app is using, and afterwards it can impersonate the good app during OAuth authorization.

I don't think there's any validation we can do, but we should highlight custom protocols somehow for the OAuth admin so they can check it and catch at least high-profile issues (like someone trying to register wikipedia:). And, yes, disable auto-approval.

Ideally we'd warn if another registered app uses the same protocol, but that seems like a fair amount of effort.

What is the threat model for allowing an OAuth app to register a URL they don't own?

As I understand it, we don't validate or prove ownership of regular HTTPS URLs today when registering OAuth apps. If you register https://example.org/callback as yours but don't actually own it, then an authorization attempt can (presumalby) not do much because if it doesn't redirect to a website you control, it doesn't work. The ownership is implicitly verified by two parties (us and the registered app) being able to succesfully exchange cryptographically-signed messages from our endpoint to their registered URL, and back.

Apologies for asking the obvious, but in the interest of documenting this for future reference: Why are custom protocol URLs different / more dangerous?

I'm assuming that native apps are not in the habit of exposing actions like mybank://send/money/to/me or mymail://delete/some/email (or require confirmation or CSRF). Is there some implied value or authority by having us redirect to such a URL vs a random phishing site sending you there? Generally speaking, yes, there is implied value and authority, because people are more likely to click on wikipedia.org/... than evil.example/..., and that's why we open redirects are considered a security vulnerability. But within the scope of OAuth, this an explicit requirement and applies to HTTP URLs already. Presumably this is mitigated by protecting these URLs with nonces valid for a limited time only, making them ineffective for XSS, because you can only start that redirect chain yourself.

In T412542#11937842, @Krinkle wrote:

I'm assuming that native apps are not in the habit of exposing actions like mybank://send/money/to/me or mymail://delete/some/email (or require confirmation or CSRF).

Presumably not, but if they do, that's easy to exploit directly, I don't think it's a concern for OAuth.

There is no unambiguous ownership model for URI schemes like there is for web domains, though. AIUI nothing stops you from creating your own app that listens to wikipedia: URLs. In some cases multiple apps sharing a scheme is legitimate (e.g. a number of apps handle otpauth:, which is the scheme used by those 2FA QR codes). So the threat model is (staying with that example):

• attacker creates an app registers itself as a handler for wikipedia:
• attacker registers an OAuth consumer with a wikipedia: return URL
• ...profit?

I thought there is some spoofing scenario given that setup, but now I can't really come up with one. (The attacker can extract the real Wikipedia app's secret key, send the user to the authorization dialog, which will be for the real Wikipedia app, and trick the user somehow into accepting. That's a standard attack against OAuth apps. But that doesn't involve the attacker registering their own consumer at all.) PKCE will guarantee that all requests that comprise an authorization flow are made by the same app (ie. an attacker can't wait for the real app to start it and switch midway, or the other way around). The attacker staring and ending an authorization flow that uses wikipedia: and shows the attacker's app's name on the authorization dialog seems fine.

So I guess you are right, there's no real threat model there.

Change #1288997 merged by jenkins-bot:

[mediawiki/core@master] UrlUtils: Add an option to allow any URL protocol

https://gerrit.wikimedia.org/r/1288997

Change #1293172 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/OAuth@master] Allow configuring allowed protocols for auto-approved consumers

https://gerrit.wikimedia.org/r/1293172

Change #1293173 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[operations/mediawiki-config@master] Configure wgOAuthAutoApprove['protocols']

https://gerrit.wikimedia.org/r/1293173

After reading through RfC 8252 (OAuth 2.0 for Native Apps) I think the relevant recommendation is

(8.4) For private-use URI scheme-based redirects, authorization servers SHOULD enforce the requirement in Section 7.1 that clients use schemes that are reverse domain name based. At a minimum, any private-use URI scheme that doesn't contain a period character (".") SHOULD be rejected.
(7.1) When choosing a URI scheme to associate with the app, apps MUST use a URI scheme based on a domain name under their control, expressed in reverse order, as recommended by Section 3.8 of [RFC7595] for private-use URI schemes.

It's not really feasible to verify domain ownership, but enforcing more than zero periods seems like a good idea. That would also take care of concerns about abusing standard schemes like javascript: in redirect URIs. Since we have manual review, we could just rely on OAuth admins to spot dangerous schemes, but it's probably better to just follow the recommendation.
And we should document that the expected format for custom URI schemes is (the reverse of) your own domain, if the spec goes as far as making it a MUST recommendation for clients.

Change #1288998 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] Allow any URL protocol for OAuth app callback URLs

https://gerrit.wikimedia.org/r/1288998

Change #1293172 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] Allow configuring allowed protocols for auto-approved consumers

https://gerrit.wikimedia.org/r/1293172

The way to prevent hijacking of custom URI schemes is to ask mobile apps to use HTTPS callback URIs, which are registered with the OS as Universal Links (iOS) or App Links (Android). I wonder whether that's a better, more supportable solution here than allowing for custom schemes?

The only downside is that it would require all mobile apps to have a domain that they can use for this. So maybe it's fine to have this as a fallback, but encourage the use of HTTPS callbacks for improved security.