OAuth2.0 Implicit Grant flow. Why use url hash fragments?

Question

Going through the new OAuth2.0 Specs ( rfc 6749 ), I see that Implicit Grant protocol workflow uses Url Hash Fragments to exchange the 'access_token' between the Authorisation server and the public client.

See Specs: http://tools.ietf.org/html/rfc6749#section-4.2

Cannot the Authorisation grant response be send as 'Query Params' instead of the Url fragment, keeping other parts of the flow as it is ?

Basically I cannot understand the limitation that made spec authors of OAuth2 chose url hash fragments for Implicit grant flow authorisation ?

Answer 1

the Implicit Grant flow is done for java script clients and I think they are using '#' instead of '?' to not send the access token to server side of your redirect URL but it is still reach to javascript which is the client in our case may be for security reason "not sharing your access token over network may be unsecured like one used for redirect URL"

Answer 2

Adding my 2 cents ..

The URI Fragment is used instead of query parameter , from security point of view. The URI segment will never be sent over the network to the redirect url. For e.g. after login on the Oauth Authorization server, the location header will have "ur redirect url"#access_token=uraccesstoken and the response code will be 302. When the browser sees the 302, it will redirect to the location header value automatically (the user agent does it automatically and the javascript cannot stop this (afaik) ).

Since its a URI fragment, only the redirect url is sent across the network, the uri fragment is not.

If it was a query parameter, the query parameter will also be sent over the network. Even with TLS, the query parameter will be visible in your proxy logs, making our access token known to unintended people, causing a leak of the access token.