0

I'm testing a Qt based OAuth library (https://github.com/pipacs/o2). I'm testing OAuth 2.0 against Facebook as the provider.

I'm testing the ImplicitGrant flow of the protocol. In this flow, if a client sets the *request_type* query param to token, then the response is included as a URL fragment and contains an access token.

Facebook, on successful authentication in the browser, responds back with a redirect to the uri that I provide and the access token is sent in the URL fragment.

Eg: the browser is redirected to:

http://mylocalserver.com:8888/#access_token=ABCDE&expires_in=5162322

mylocalserver.com=localhost

I have a tiny HTTP server implemented in Qt which handles all such redirects.

The problem is that on getting an incoming connection, i.e from the browser which initiated it on a redirect, when I read the data from the socket, I see that the fragment part is missing! Eg: for the above local url, the data I'm seeing is:

GET / HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

As you can see the fragment is completely missing. Looking around for this problem, I found that FF/Chrome might put fragments in the Location header. But I don't see that either.

Any idea as to why the fragment is getting lost and how to get it back/instruct the browser to send it?

Mandeep Sandhu
  • 301
  • 1
  • 4
  • 9

1 Answers1

0

The implict flow is meant to be used in situations where there's no "server". Fragments (and the access token in it) would be extracted by client side code (e.g. javascript, native clients, etc). That is for situations where you can't keep a secret securely. When you can (as in a server), you typically use the authorization code flow. The fragment missing in the GET to the server is expected.

Eugenio Pace
  • 14,094
  • 1
  • 34
  • 43
  • You're right, in that the fragment part is retained by the "User Agent" as is mentioned in the OAuth 2 draft spec: http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.2 However, a web-server is still expected as the user-agent is supposed to act on the redirect from the authorization server. Though, I don't know how the "User Agent" is expected to *retain* the URI fragment. Are they expecting some custom "browser"? Currently I'm simply opening whatever default browser the user has configured for opening the Facebook login dialog (for OAuth). Thanks. – Mandeep Sandhu Jul 24 '13 at 10:19
  • No web server is normally used with implicit flow. The redirect is intercepted and you use client side javascript to extract the token. – Eugenio Pace Jul 24 '13 at 15:06
  • Thanks Eugenio. I'll try intercepting the redirect with my custom user agent. – Mandeep Sandhu Jul 25 '13 at 04:43