Reputation: 34800
I want to make sure I have correctly understood the (draft) spec, which states:
The redirection endpoint URI MUST be an absolute URI as defined by
[RFC3986] section 4.3. The endpoint URI MAY include an
"application/x-www-form-urlencoded" formatted
([W3C.REC-html401-19991224]) query component ([RFC3986] section 3.4), which MUST be retained when adding additional query parameters. The
endpoint URI MUST NOT include a fragment component.
Reason I ask is that neither Google or Facebook appear to preserve any querystrings.
Upvotes: 4
Views: 5012
Reputation: 335
Re-reading the spec it appears that the quoted section of the spec applies not to the OAuth server's handling of URIs but the OAuth client's handling of the original endpoint URI it is given.
In other words it's saying that if I say that my OAuth endpoint which you have to use when redirecting to my server for an OAuth authorization is:
http://example.com/oauth.php?endpoint=token
Then when the client is adding the ?response_type=code&client_id=...&state=...&redirect_uri=...
to the URI it is not permitted to discard the "?endpoint=token" in the original endpoint uri and MUST use the URI:
http://example.com/oauth.php?endpoint=token&response_type=code&client_id=...&state=...&redirect_uri=...
So, at least as far as that part of the spec goes there's nothing there saying that Facebook, Google, etc... have to preserve any unknown query arguments besides the 'state' one.
Technically you might be able to use the &state=
parameter to pass along custom data in say JSON format. Though that may or may not work. IIRC I noticed that Meetup's implementation of OAuth 2 appears to mangle the state when you use special characters. Something that I believe is against spec.
Upvotes: 6