"Required parameter is missing: response_type" error when requesting access_token from web app
11,459 views
Skip to first unread message
Jim Eng
Dec 20, 2012, 9:51:43 AM12/20/12
to oauth...@googlegroups.com
We are writing a web application that, among other things, will use the calendar API to retrieve data and add events to a couple calendars, but we're running into a problem using OAuth2. We get an error message at the final step, when we have received the authorization code and we are posting a request back to the OAuth server asking for the access token. This is described under "Handling the Response" in the documentation for usinf OAuth 2.0 for Web Server Applications [1].
The response we get to POSTing the request is a Net::HTTPBadRequest (i.e. error code 400) with a response body that says "Required parameter is missing: response_type". This seems suspicious because response_type is a parameter required in an earlier request but not in this step of the process.
ASIDE: We've tried a lot of silly things, such as including a "response_type" parameter in this request, though there's no documentation of that and therefore no indication of what value would be used at this point (using "response_type=access_token" returns an error saying "access_token" is an invalid value, but using "response_type=token" or "response_type=code" does not). If we supply a value for response_type, we next get another error saying we're missing the "scope" parameter. If we supply that, we get an error saying "client_secret" is not a valid parameter for this request. That suggests that the OAuth server is trying to treat this as a request for an authorization code rather than the later step of trying to exchange the authorization code for an access_token.
The error message also echos back the values that have been submitted for the five required parameters at this step, and they all look good. We've read various forum posts that discuss similar symptoms, but none seem to suggest anything that makes sense to this situation. This is being done in a Ruby-on-Rails app. We tried using Google's newest Ruby client, and we've written our own client using ActiveRecord::Connection to POST the request, and later we switched to using Net::HttpPost and Net::Http directly in case something in the Rails code was interfering. We can post code fragments and debugging output if that helps.
We'd appreciate any suggestions.
[1] https://developers.google.com/accounts/docs/OAuth2WebServer#handlingtheresponse
The response we get to POSTing the request is a Net::HTTPBadRequest (i.e. error code 400) with a response body that says "Required parameter is missing: response_type". This seems suspicious because response_type is a parameter required in an earlier request but not in this step of the process.
ASIDE: We've tried a lot of silly things, such as including a "response_type" parameter in this request, though there's no documentation of that and therefore no indication of what value would be used at this point (using "response_type=access_token" returns an error saying "access_token" is an invalid value, but using "response_type=token" or "response_type=code" does not). If we supply a value for response_type, we next get another error saying we're missing the "scope" parameter. If we supply that, we get an error saying "client_secret" is not a valid parameter for this request. That suggests that the OAuth server is trying to treat this as a request for an authorization code rather than the later step of trying to exchange the authorization code for an access_token.
The error message also echos back the values that have been submitted for the five required parameters at this step, and they all look good. We've read various forum posts that discuss similar symptoms, but none seem to suggest anything that makes sense to this situation. This is being done in a Ruby-on-Rails app. We tried using Google's newest Ruby client, and we've written our own client using ActiveRecord::Connection to POST the request, and later we switched to using Net::HttpPost and Net::Http directly in case something in the Rails code was interfering. We can post code fragments and debugging output if that helps.
We'd appreciate any suggestions.
[1] https://developers.google.com/accounts/docs/OAuth2WebServer#handlingtheresponse
Jim Eng
Dec 20, 2012, 10:09:25 AM12/20/12
to oauth...@googlegroups.com
Here are the parameters as echoed back in the response (with secrets removed):
Jim Eng
Dec 20, 2012, 12:55:34 PM12/20/12
to oauth...@googlegroups.com
Solved.
We were using the wrong path when trying to exchange the authorization code for an access token. The path should be "/o/oauth2/token". Now that I know that, I see it a couple places in the documentation, but it is not clear in the documentation (or at least in the page I cited earlier). The documentation should be revised to make this explicit. Specifically, in that page, the section on "Forming the URL" gives the "Endpoint" as "
Anyway, if the documentation does not get fixed, I hope people who face this problem in the future find this forum post to help them avoid wasting lots of time.
BTW, the way we discovered this was that we went to the APIs Console to double- and triple-check my client_id and client_secret. There we notices a link to download JSON related to our registration. The JSON had a value for "auth_uri" and another for "token_uri". We simultaneously experience an AH-HA moment and an OH-DOO-DOO moment.
We were using the wrong path when trying to exchange the authorization code for an access token. The path should be "/o/oauth2/token". Now that I know that, I see it a couple places in the documentation, but it is not clear in the documentation (or at least in the page I cited earlier). The documentation should be revised to make this explicit. Specifically, in that page, the section on "Forming the URL" gives the "Endpoint" as "
https://accounts.google.com/o/oauth2/auth" and the description says that URL should be used for requesting access tokens, refresh tokens and authorization codes (if I read that correctly). The section of "Handling the Response" does not correct that, but the example of a request does gave the correct path. Too bad it's not clear that the path is different for this purpose. The section on refresh tokens gives the correct URL, but we are not (yet) using refresh tokens, so we missed that. Anyway, if the documentation does not get fixed, I hope people who face this problem in the future find this forum post to help them avoid wasting lots of time.
BTW, the way we discovered this was that we went to the APIs Console to double- and triple-check my client_id and client_secret. There we notices a link to download JSON related to our registration. The JSON had a value for "auth_uri" and another for "token_uri". We simultaneously experience an AH-HA moment and an OH-DOO-DOO moment.
Reply all
Reply to author
Forward
0 new messages