I haven't gone over the final spec in depth yet, so I can't really address OAuth 2.0-final specifics.
In general though, I think the ease of development that comes from query strings trumps any supposed security gains of using headers for passing parameters.
Fundamentally, if you're worried about secrets being logged you're worried about MITM attacks (if either endpoint stores secrets insecurely, that's a whole other concern). If someone's actually managed to MITM a user, it's no harder to capture headers than query strings; so it's a mostly false sense of security. To prevent MITMs, you should just mandate HTTPS; that gives you some real improvement, not just one for the very narrow "traffic logs subsequently compromised" case (and even that assumes the log in question isn't capturing headers, which may be typical but is by no means universal).
Yup, just on the question of putting secrets into get request params vs. headers.
OAuth2 does require SSL, and you're right that both params and headers are equally protected there.
My main concern with putting "secrets" in query strings is that traditionally sensitive data doesn't go in query strings -- it'd be in POST content, normally -- so both browsers and servers are less careful with that data.
Headers DO sometimes contain sensitive data (i.e., standard http auth), so there's a history there, and by default this info would be protected a bit more than GET params, I think.
I do care about the endpoints, for two reasons -- on the server side, a log accidentally containing sensitive data might contain all of the secret tokens for the service, and logs are generally not as carefully protected as, say, the database, so they might be posted for developer review or otherwise exposed.
On the client-side: if a single client is hacked, that's normally just one token exposed (whether it was being passed via header or param, probably). But if the browser simply isn't treating the token as secret data, then it gets around -- addons might send queries out to a server for various contextual features, Google may collect it (to help live search dropdowns), etc. -- it's simply not treated as carefully, so it gets out.
Of course, production uses (vs. developers wandering around) generally wouldn't even be using a browser (and I could personally make sure these params weren't in our logs), so none of this is disastrous; just issues on my mind.
Comments
I haven't gone over the final spec in depth yet, so I can't really address OAuth 2.0-final specifics.
In general though, I think the ease of development that comes from query strings trumps any supposed security gains of using headers for passing parameters.
Fundamentally, if you're worried about secrets being logged you're worried about MITM attacks (if either endpoint stores secrets insecurely, that's a whole other concern). If someone's actually managed to MITM a user, it's no harder to capture headers than query strings; so it's a mostly false sense of security. To prevent MITMs, you should just mandate HTTPS; that gives you some real improvement, not just one for the very narrow "traffic logs subsequently compromised" case (and even that assumes the log in question isn't capturing headers, which may be typical but is by no means universal).
Yup, just on the question of putting secrets into get request params vs. headers.
OAuth2 does require SSL, and you're right that both params and headers are equally protected there.
My main concern with putting "secrets" in query strings is that traditionally sensitive data doesn't go in query strings -- it'd be in POST content, normally -- so both browsers and servers are less careful with that data.
Headers DO sometimes contain sensitive data (i.e., standard http auth), so there's a history there, and by default this info would be protected a bit more than GET params, I think.
I do care about the endpoints, for two reasons -- on the server side, a log accidentally containing sensitive data might contain all of the secret tokens for the service, and logs are generally not as carefully protected as, say, the database, so they might be posted for developer review or otherwise exposed.
On the client-side: if a single client is hacked, that's normally just one token exposed (whether it was being passed via header or param, probably). But if the browser simply isn't treating the token as secret data, then it gets around -- addons might send queries out to a server for various contextual features, Google may collect it (to help live search dropdowns), etc. -- it's simply not treated as carefully, so it gets out.
Of course, production uses (vs. developers wandering around) generally wouldn't even be using a browser (and I could personally make sure these params weren't in our logs), so none of this is disastrous; just issues on my mind.