Q:

Mobile authentication with password as param in get request over ssl

I'm building out a new services layer for an existing mobile application. The mobile application authenticates with the existing services layer by providing the user name and password as url params in a get request to the authentication end point. This all happens over ssl.
Initially I thought this was insecure, but this post seems to suggest it's not insecure at the transport layer SSL with GET and POST. The only concern is how the request is logged by the server. Given I'm writing the server side and can control logging, is this something I should worry about. Should I insist the app team change the client to send a post request to better secure the password, or is that unecessary?

A:

Yes, insist to change the request to POST. 
The main issue here is the fact username and password will be saved in logs. As best practice no logs should contain sensitive information even if they are very secured. 
This is clearly specified in rfc2616:

15.1.3 Encoding Sensitive Information in URI's
Because the source of a link might be private information or might
  reveal an otherwise private information source, it is strongly
  recommended that the user be able to select whether or not the Referer
  field is sent. For example, a browser client could have a toggle
  switch for browsing openly/anonymously, which would respectively
  enable/disable the sending of Referer and From information.
Clients SHOULD NOT include a Referer header field in a (non-secure)
  HTTP request if the referring page was transferred with a secure
  protocol.
Authors of services which use the HTTP protocol SHOULD NOT use GET
  based forms for the submission of sensitive data, because this will
  cause this data to be encoded in the Request-URI. Many existing
  servers, proxies, and user agents will log the request URI in some
  place where it might be visible to third parties. Servers can use
  POST-based form submission instead

