CAS REST authentication API accepts text/* but not

I have configured my CAS server to activate REST authentication, as per these instructions. However, in order for it to work, I must submit my credentials in plain text (content type text/html or xml) and not application/x-www-form-urlencoded as per the instructions. The credentials are lost when sent in the latter format.

I am uncomfortable sending my login credentials in plain text. Is this a bug in CAS and how can it be fixed? I am assuming it is less secure to send login credentials as text content type vs application, as the latter (I assume) does hash (or somehow else obfuscates) the content sent.

I should also mention that I had to make a fix to a bug in CAS due to which credentials were being lost regardless of the content type, by implementing this solution in my maven overlay. After that, only text-based content types worked and CAS does authenticate (albeit I find it annoying that the service returns HTML and not XML/JSON or even plain text, for the ease of programmatic processing).

RELATED: REST API endpoint /v1/tickets appears to lose credential request parameters

Content-type has no effect on the confidentiality of data in the request. Sending it with application/x-www-form-urlencoded in a request is not more (nor less) secure than text/html or text/xml if only confidentiality is considered. There is no additional security value in using any of those in a request, somebody having access to the raw request source (a MitM attacker) will see request contents either way. HTTPS effectively mitigates this risk with regard to MitM attackers on the network inbetween nodes, but not on endpoints where SSL is terminated (the source and target computers, and also any node inbetween that terminates SSL, like for example a company proxy with a trusted root certificate on clients - a fairly common setup).

As for the possible security benefit of using text/plain instead of application/x-www-form-urlencoded, please see my answer to your other question. In short, using text/plain may prevent some CSRF attacks.