Why deploy TLS is a significant hurdle for many client developers

Question

I have a question on RFC 6749 about OAuth 2.0..

In this section I read:

3.1.2.1. Endpoint Request Confidentiality

The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of
sensitive credentials over an open network. This specification does
not mandate the use of TLS because at the time of this writing,
requiring clients to deploy TLS is a significant hurdle for many
client developers. If TLS is not available, the authorization server SHOULD warn the resource owner about the insecure endpoint prior to
redirection (e.g., display a message during the authorization
request).

Lack of transport-layer security can have a severe impact on the
security of the client and the protected resources it is authorized
to access. The use of transport-layer security is particularly
critical when the authorization process is used as a form of
delegated end-user authentication by the client (e.g., third-party
sign-in service).

..in particular:

This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for many client developers.

Why deploy TLS is a significant hurdle for many client developers?

Answer 1

Public key infrastructure is quite complex and not many developers understand it enough to implement it right even on the client side. This leads to false security which is worse then no security (as it misleads people).

As an example I can remember a recent research which has shown that in many Android applications client software uses SSL/TLS but accepts any certificate without proper validation. This leads to possibility of MITM attacks and what is worse, the user (owner of the device) thinks that he is secured while he's in fact not.

And what is even worse, developers don't want to invest in security-related education as this doesn't increase profits.

Answer 2

This text is unfortunate, I will open an editorial errata against RFC 6749. My understanding of this language, was that it meant to allow "native clients" (desktop/tablet/mobile apps) to offer a non-SSL URL. Often, this takes the form of a "custom URL scheme".

The idea is that the browser will "redirect locally" to these clients and provide them with an authorization code. So the code is never transferred over the network and hence no need for a secured redirect URL. Similar considerations apply when the redirect URL is of the form h-t-t-p localhost:xyz/redirect_endpoint.

Generally speaking, developers dont have to do anything to deploy against SSL. It is the admins who would have to spin up a https port and deploy an application endpoint on a web server. This is a common deployment scenario. But again, this is not usually practical for a native client.