11

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

Dhairyashil
  • 179
  • 2
  • 5
  • 18
Karthik
  • 345
  • 3
  • 11

3 Answers3

9

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/

user3101375
  • 111
  • 1
  • 2
  • vlatko - you are correct to say that the URI fragment has some special properties and so strictly speaking my above comments do not apply. However, this is a very fragile aspect of the message exchange - you are literally depending on a specific behavior of the browser on a re-direct to protect the flow (that it omits the fragment component of a URI on a re-direct). If the URI fragment does get picked up someplace it yields a multi-use token for the attacker. – user3101375 Jan 15 '14 at 00:52
  • You are totally correct. This type of authentication is insecure by definition. – Patrick Hofman Jun 11 '15 at 14:09
2

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.

Community
  • 1
  • 1
vlatko
  • 3,234
  • 1
  • 18
  • 11
  • Even when access token is sent through https, since its a fragment, will it not be possible for intermediate hop servers in the network to sniff it – Karthik Jan 18 '13 at 02:04
2

Elaborating on @vlatko's response...

To mitigate the risk of sending the token in the fragment (or via any other OAuth2 grant):

Issuing short-lived access token (as @vlatko said) will reduce the impact of a leaked token, but is not a preventative measure.

Community
  • 1
  • 1
codeprogression
  • 3,371
  • 1
  • 22
  • 16
  • 1
    Even when access token is sent through https, since its a fragment, will it not be possible for intermediate hop servers in the network to sniff it. – Karthik Jan 18 '13 at 02:03
  • Did you mean even if its sent through http? – codeprogression Jan 18 '13 at 02:24
  • If we assume Oauth Server as X, and the client requesting access as Y. Then even when access token is sent as fragment in https, from X to Y, the intermediate machines in the www network from X to Y can read this access token (ie: eavesdropping on https query params/fragments is, as easy as eavesdropping an http query params/fragments). Only data in HTTP body is encrypted in case of https. – Karthik Jan 20 '13 at 16:31
  • 1
    See these questions: http://stackoverflow.com/questions/8858102/with-https-are-the-url-and-the-request-headers-protected-as-the-request-body-is?lq=1 http://stackoverflow.com/questions/499591/are-https-urls-encrypted – codeprogression Jan 20 '13 at 23:44
  • @Karthik Your comment "Only data in HTTP body is encrypted in case of https" is not true. In HTTPS the entire HTTP payload is encrypted. That includes headers/body/URL etc. – Harry Jun 30 '16 at 05:31