In Implicit Grant, the access token is sent back in the callback URL. Is this not a security risk because, if this callback URL is cached in the hop. In general it is advised, not to send sensitive data in URL params, and this access token will be a token to access all secured user resources. So why is it getting passed as fragment in URL
Elaborating on @vlatko's response...
To mitigate the risk of sending the token in the fragment (or via any other OAuth2 grant):
- ensure that the OAuth endpoint and the callback endpoint are TLS (https) (See countermeasures)
- send a state parameter to prevent cross-site forgery (Also see: http://tools.ietf.org/html/rfc6749#section-4.2.1)
Issuing short-lived access token (as @vlatko said) will reduce the impact of a leaked token, but is not a preventative measure.
Hmmm, I am afraid there are some misunderstandings in the answers above. While URL query strings are secured when using TLS, and thus the access token is protected in flight, it is exposed in the users browser (part of their history) and also in the destination web browser logs. Most web browsers will log the entire URL of the incoming request. Their is an additional issue known as the "referer" leak problem wherein the query string will be passed to third-party sites. A good overview may be found at:
http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Like you pointed out, the token is passed the URI fragment. Since browsers don't send fragments of URLs to HTTP servers, the chances that someone will eavesdrop and pick up the access token are drastically reduced.
There are also additional security measures, like only issuing short lived access tokens in the implicit grant flow.
More info in the OAuth2 threat models document.
来源：https://stackoverflow.com/questions/14297805/how-secure-is-oauth-2-0-implicit-grant