3

I was reading here that when passing a client_id and client_secret to an authorization server,

The parameters can only be transmitted in the request-body and MUST NOT be included in the request URI.

  • What are the possible dangers of posting these parameters in the request uri?
  • Should the server not provide an access token to the client if these parameters are in the request uri instead of the body?
Community
  • 1
martin
  • 155
  • 6

1 Answers1

3

Should the server not provide an access token to the client if these parameters are in the request uri instead of the body?

This probably makes sense in order to educate programmers (if they don't get an access token, then they'll learn to do it the right way), but it wouldn't make the system more secure if it was under attack. If the client id and client secret were stolen, then the attacker could impersonate the client and get a valid access token by sending a correct request (with the id and secret in the message body).

What are the possible dangers of posting these parameters in the request uri?

If you use https to communicate with your endpoint and you trust your access token provider, the danger would probably be small.

The client id and secret can show up in your browser history if you're sending them directly from the browser and could probably be stolen from it via malicious javascript, which I'd think would be the greatest risk. (But note that if you entrust browser javascript with your client id and secret, then they are already unsecure...)

The id and secret could also be stolen at the other end of the connection, since they show up in the web server logs of the server you send it to, but because you're sending your client credentials to a provider who already has them, and who hopefully knows how to keep his systems secure, I'd think this wasn't a likely point of compromise.

If you use unencrypted http, then the client id and secret might end up in logs of caches and proxies. Whether somone who sniffs your traffic can see the URL is only midly relevant; since in order to do that he has to look at the request, and therefore could also see the id and secret if they were sent in the request body.

Out of Band
  • 9,150
  • 1
  • 21
  • 30
  • Why is the danger small if using HTTPS? You are including the client ID and secret in the request URI, which is not encrypted. Only the HTTPS data payload is encrypted, so wouldn’t an attacker be able to easily sniff this packet and grab the credentials? – Yu Chen Sep 05 '19 at 01:27
  • 1
    I'm not sure what you mean by "only the https data payload is encrypted". HTTPS (or rather TLS) provides an encrypted layer which encapsulates the HTTP protocol, so the request URI, which is part of the HTTP GET request, gets encrypted along with everything else that belongs to the request. You can prove this to yourself by watching an HTTPS connection with a tool such as wireshark - the only thing you'll see in the clear is the hostname and some certificate information - no HTTP whatsoever. – Out of Band Sep 05 '19 at 20:29
  • Wow. I... never knew that. Was always under the impression only data payload was encrypted. – Yu Chen Sep 05 '19 at 23:31