Reasons for recommending loopback redirects over private-use URI scheme

[archer-321]

The current OAuth 2.1 draft mentions that

Many environments that support private-use URI schemes do not provide a mechanism to claim a scheme and prevent other parties from using another application's scheme. As such, clients using private-use URI schemes are vulnerable to potential attacks on their redirect URIs, so this option should only be used if the previously mentioned more secure options are not available.

AFAICT, this paragraph was introduced by f428704c for the reasons outlined in the ietf-113 minutes:

George: I am in favor of ordering of best security practive starting with the claimed https URL. Aaron: It sounds like we are going to re-order the list, claimed https URL first, loopback second, and private URI schemes. Remove the sentence for the mandatory -implementing all three. Maybe adding text of why you want to have the private URI scheme at all.

Considering that any app can listen on the loopback interface and thus create a valid redirect URI that leads to itself, I wonder what makes loopback redirects more secure than private-use URI schemes.

One potential advantage of loopback redirects that I can see is that only one app can listen on the specific port. Thus, it's impossible for an attacker to receive a code that was the result of a valid authorization request if the client has already started its loopback HTTP server. However, integrating PKCE into OAuth 2.1 should already prevent this attack. Moreover, using the authorization code grant type already prevents MITM attacks, public clients can't use the client credentials grant type, and the implicit grant type was removed.

On the other hand, most operating systems require some sort of installation procedure (installing a .desktop file, creating a registry entry, installing an app with a manifest, etc.) before user agents consider an application for the private-use URI scheme. While this is not a "true" security feature that protects against redirect code interception, as multiple applications can register themselves for the same scheme, it prevents users with access to the same loopback device but without access to the same user account or the system-wide scheme handler registry from intercepting a code. In comparison, any user on the same computer can bind a port on the loopback device and thus obtain a valid redirect URI that points to itself.

---

I agree that all native clients should prefer claimed "https" schemes where possible, but unless I'm missing something, I would suggest changing the paragraph above to something like

Many environments that support private-use URI schemes do not provide a mechanism to claim a scheme and prevent other parties from using another application's scheme. As such, clients using private-use URI schemes are vulnerable to potential attacks on their redirect URIs, so this option should only be used if claimed https schemes are not available.

[dickhardt]

@archer-321 are you suggesting dropping loopback?

I think loopback is preferable to private schemes in that you can't MITM it. A malicious app does not know when a protocol is happening. In contrast, if an malicious app registers a private scheme, then it could be intercepting the protocol.

Mobile platforms generally support claimed https and pretty much any app can claim a private scheme. On desktop, the loopback is generally preferable. A common use case are CLI tools that launch the browser -- claiming an https endpoint, or registering a private scheme are not really practical.

[archer-321]

@archer-321 are you suggesting dropping loopback?

No, I believe loopback is still essential for many native client implementations, and there would be no reason to drop this well-established redirect type. I was merely suggesting rephrasing the private-use redirect URI scheme section I quoted, as I didn't see the security advantages of loopback over private-use URI schemes mentioned.

I think loopback is preferable to private schemes in that you can't MITM it. A malicious app does not know when a protocol is happening. In contrast, if an malicious app registers a private scheme, then it could be intercepting the protocol.

Considering the only grant type available to public clients in OAuth 2.1 is the authorization code grant, how could an attacker MITM the authorization "ceremony"? If they manage to intercept the authorization code, it would either be useless when the legitimate client has obtained an access token, or the legitimate client would encounter an error while trying to retrieve an access token after the attacker has already used the code.

One aspect you mentioned that I didn't consider is that attackers are more likely to notice that an authorization ceremony is happening. However, this could also be established by watching all processes until an instance of the client application binds a port on the loopback interface, so I'm unsure how much security the protocol gets here.

The primary reason I prefer private-use redirect URIs over loopback is that some services incorrectly implement the user-interaction part of the authorization endpoint. E.g., GitHub doesn't seem to ask for interaction if the user has previously authorized the application. If the application uses a loopback redirect URI, even a process running as another user could create a loopback HTTP server. The only thing a malicious client would have to do in this case to get access to the protected resource is redirect the user to the authorization endpoint somehow (e.g. by sending the user a link or by putting the link on a website the attacker controls - even adding the link to the description of a pull request would work).

With private-use URI schemes, the attacker would have to get a system administrator to install it as a scheme handler. Alternatively, the attacker would need access to the user configuration to set up the scheme handler for a single user. Again, I wouldn't count this as a foolproof security feature, but in my head, it makes attacks more complex, at least.

Mobile platforms generally support claimed https and pretty much any app can claim a private scheme. On desktop, the loopback is generally preferable. A common use case are CLI tools that launch the browser -- claiming an https endpoint, or registering a private scheme are not really practical.

I agree that mobile apps (and apps on other systems with the feature) should prefer claimed "https" schemes over both loopback redirect URIs and private-use URI schemes. I also agree that CLI tools that ship as a single binary without any installer or package should be able to use loopback. My main concern is that, in my opinion, the quoted paragraph of the specification "unfairly" treats private-use URI schemes as less secure than loopback redirects ("[...] this option should only be used if the previously mentioned more secure options are not available"). This wording might make future implementing services not consider support for private-use URI schemes while instead forcing apps to use loopback.