22

Just noticed that in OAuth2 when the requested grant type is: "code" the callback contains it in the query string parameters (after '?'). However, when the grant is "token" it is passed as a fragment (after '#').

This looks to be part of a spec (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.2)

What could be a rationale behind such decision?

Thanks, Piotr

Improve this question

1 Answer 1

Reset to default
24

When your browser gets redirected by a website to a URL with a query parameter, the query string is also part of the request that your browser now sends to the host. Fragments are only evaluated locally by your web browser and not included into the request to the host.

In case of the Authorization Code Grant, where you typically have a web application, that directly talks to a provider, sending the data to the host is exactly what you need:

  • The web application redirects your browser to the provider where you log in.
  • The provider now tells your browser a callback URL of the web application and appends an authorization code. This code has to be sent to the web application, so it is included as a query parameter into the request to the callback URL.
  • The web application now itself talks to the provider in the background and verifies with the authorization code that he is indeed allowed to query the provider for an access token.

In case of the Implicit Grant, you typically have some Javascript application directly running in your browser. There's no need to pass any authorization code to the host and in most cases there's also no need to send the access token to the host, as the JS in the browser can directly talk to the provider. This way you could e.g. create a website on a server that uses information queried from another provider with consent from the user where the server never gets access to any confidential data of the user. (In case of a trusted website, that doesn't send the access token to the server.)

Improve this answer
2
  • 2
    This is a great explanation. A gotcha that I am currently running into is that not all user-agents (Safari being one) reliably pass on the fragment as part of a redirect. Oddly, the fragment is present over http, but goes missing over https. As such, I've gone the route of using the query string which of course is less desirable for the reasons you mention.
    – d0nut
    Commented May 1, 2013 at 22:35
  • @d0nut i was able to support Safari with third parties and the fragment by preloading the popup window with the page which handles the oauth callback response... i dont know why it works but it does. Checkout adodson.com/hello.js
    – Drew
    Commented Jan 10, 2014 at 11:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.