Gmail OAuth API has been working well until Feb 17th, and POST /o/oauth2/token randomly returns this error while refreshing OAuth token:
Parameter not allowed for this message type: redirect_uri
The error occurs about 1 out of 10 times. What's strange is that, after receiving this error, the next exact same request succeeded. So this is not related to "redirect_uri" as suggested by the error message.
"Parameter not allowed for this message type" has been reported in other StackOverflow posts, but they are all persistent errors and can be resolved by fixing the parameters. While the error we got is temporary. The 10% rate is costly to the user experience.
Has anyone seen similar behavior lately?
It seems Google has recently changed the url for getting a new access token from a refresh token. The older url was https://accounts.google.com/o/oauth2/token and the new one is https://www.googleapis.com/oauth2/v4/token.
Also I remember that redirect_uri was previously among the parameters for getting a new access token, but it no longer seems to be there: https://developers.google.com/identity/protocols/OAuth2WebServer#offline. Just look at the HTTP/REST example.
It is possible that just removing redirect_uri works even with the older url, but I think it is wise to both change the url and remove redirect_uri.
I'm unable to add a comment above, but we've been seeing a similar issue too with intermittent failures on oauth.
Removing the "redirect_uri" worked, though that makes me nervous since the documentation https://developers.google.com/identity/protocols/OAuth2WebServer says to include it.
What does work, though, and allows us to keep the "redirect_uri" is updating our url from https://accounts.google.com/o/oauth2/token to https://www.googleapis.com/oauth2/v4/token
Related
I'm attempting to interact with the Google Sheets API and running into an inexplicable problem that I'm finally reaching out to see how anyone else may have tackled it. Put simply, I can use the in-page API Explorer tool with only the https://www.googleapis.com/auth/spreadsheets.readonly OAuth2 scope at https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets/get to query my spreadsheet (just the spreadsheet ID, leaving all other fields to empty defaults) and I'll see the 200 with the response in the bottom as expected.
Of course, I can't re-use the same access token that tool uses, but if provision an access code for the same user for my own app (same scope), and make the same GET request to https://sheets.googleapis.com/v4/spreadsheets/<spreadsheetId> in Postman (again, no other fields populated), substituting the access token into the Authentication header with Bearer <accessToken>, I get a 404.
I know the file is there - I've triple checked that I'm using the same spreadsheet ID across either request and I'm consistently getting a 404 (not a 401 or 403) indicating that my access token does authenticate.
I've tried broadening my OAuth2 scopes to include the full range listed on the API Explorer:
https://www.googleapis.com/auth/drive
https://www.googleapis.com/auth/drive.file
https://www.googleapis.com/auth/drive.readonly
https://www.googleapis.com/auth/spreadsheets
https://www.googleapis.com/auth/spreadsheets.readonly
Of course, I don't want to have to use all those scopes for my purposes - I'd like to use the most narrow scope possible, but I also wanted to rule out that it wasn't failing to work for some scoping scenario. No difference - still a 404 every time I make the request in Postman. I've tried issuing multiple access tokens now, using accounts.google.com to invalidate the tokens for my app between re-issuances, but to no avail.
To be clear, the Google Sheets API has been enabled for my app.
In hopes that someone else has experienced the same inability to query Google's v4 REST API despite using valid access tokens, could you share how you managed to do it?
I appreciate it!
Update:
So I've been playing around with the OAuth 2.0 Playground shared in the comments and found that the authorization endpoint I was using was identical, but the token endpoint differed. This doesn't seem to matter since I used the custom option to use the alternate endpoint and the Playground was still able to work without issue just like the API Explorer.
Using the custom entries, I also entered my own app's client ID and client secret (after registering the playground redirect URI), minimizing the differences between what I'm doing in Postman and in the various Google tools. Again, my GET request to the spreadsheet works without issue.
Just to be clear, here's what I've been doing in the Playground:
In Step 1, I've specified the https://www.googleapis.com/auth/spreadsheets.readonly scope to authorize. I click the Authorize APIs button and log in with the user account.
It returns with the authorization code, so I exchange that code for the tokens via a POST to the token endpoint.
I then make a GET request to https://sheets.googleapis.com/v4/spreadsheets/<spreadsheetId> with no additional headers and it works without issue - 200 OK and all the data I'm expecting to see.
Here my approach in Postman:
Make a GET request to:
https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&response_type=code&redirect_uri=https://<myDomain>/oauthResp&client_id=<appClientId>&scope=https://www.googleapis.com/auth/spreadsheets.readonly&state=abc123
Receive a response similar to the following in my browser on the redirect (since the domain intentionally 404s).
https:///oauthResp?state=abc123&code=zyx098&scope=https://www.googleapis.com/auth/spreadsheets.readonly
Make a POST request to: https://www.googleapis.com/oauth2/v4/token with a body of:
client_id=<appClientId>
client_secret=<appClientSecret>
redirect_uri=https://<myDomain>/oauthResp
grant_type=authorization_code
Receive a response similar to:
{
"access_token": "abc123",
"expires_in": 3599,
"refresh_token": "zyx098",
"scope": "https://www.googleapis.com/auth/spreadsheets.readonly",
"token_type": "Bearer"
}
Make a GET request to https://sheets.googleapis.com/v4/spreadsheets/<spreadsheetId> with a 'Content-Type' header of application/json and an 'Authorization' header of Bearer abc123 (per the access token above).
Unlike the API Explorer and the OAuth 2.0 Playground, this yields a 404 - exactly the issue I've been experiencing for no obvious reason.
Further, if I simply take the fresh access token from the Playground and drop that into Postman, I get the same 404.
Any other ideas?
after successfully getting past the login page using curl in Linux (bash) with two sites that use information from the HTML-form field to accomplish this, I now also want to login to another site with my credentials that is a bit more tricky. I'm new to this and it seems that it works with OAuth so I need an access token first. With my two successfull attempts it was necessary to extract a CSRF token from the HTML code so as to prove I'm not a malicious bot. But now it's completely different and the server thinks I'm a bot (see error messages below).
Can somebody please confirm whether these are the only steps involved for logging in to an OAuth protected site:
a POST request to the server that generates the token (https://name_of_site/api/v1/auth/token)
a GET request to a password-protected part of the website using the access token from step 1
When I try step 1, I get error messages as shown below*. I inspected the website before logging in and afterwards with a browser and copied everything as cURL (bash). In the header fields of the token request I can find two more fields that look like they provide dynamic information:
x-trace-request-id
x-recaptcha-v3
I did some research and found that the request ID stays the same for some interactions that go to and from a server to facilitate identification of the client(?).
And concerning the recaptcha, I know what a recaptcha is, but I did not have to solve any captchas when accessing the site with a browser. So I'm quite unsure about these bits of information.
I strongly assume that I need to send one or both of these headers in the first step to actually get an acess token. But how could I get valid values for these parameters with cURL?
Any help is aprreciated! Please point me in the right direction. I can provide more information if needed, of course.
{"status":"ERROR","statusCode":400,"data":{"message":"Request failed with status code 400","error":"invalid_grant","error_description":"invalid credential","bot-detection-error":"MissingAdditionalAuthToken"}}
This is the error I get when I do not provide x-trace-request-id and x-recaptcha-v3
{"status":"ERROR","statusCode":400,"data":{"message":"Request failed with status code 400","error":"invalid_grant","error_description":"invalid credential","bot-detection-error":"InvalidCaptchaV3Token"}}This is the error I get when I simply use the values as copied from the old request when I used the browser
I'm having trouble with Adobe Sign's OAuth authentication -- every time I try to get my access token with my Client ID and redirect URI, I get this message:
Unable to authorize access because the client configuration is invalid: invalid_request
This is the request that I have been making (with the proper substitution for REDIRECT and CLIENTID):
https://secure.echosign.com/public/oauth? redirect_uri=REDIRECT& response_type=code& client_id=CLIENTID& scope=user_login:self+agreement_send:account
I am fairly new to OAuth and don't understand what I'm doing wrong. Could someone please explain the issues that could result in this error message?
I was having the same problem. I solved it by including the correct shard in the URL after "secure." and before ".echosign". You identify your shard by looking at the URL where you created your application.
I found this information here.
Hope this helps.
Is OK to have spaces in that https request?
If you still have a problems with this.
I think your URL is not correct.
I using this one
https://secure.na2.echosign.com/public/embeddedWidget
for adobe widget.
Adobe require same url for OAuth
https://secure.na2.echosign.com/public/oauth
Check your domain, and try. You can create widget just to see your domain
This comment might get helpful for others who are facing issue in Adobe Sign access token invalid_request.
Developer Guide on Sign API: https://opensource.adobe.com/acrobat-sign/developer_guide/index.html
For the Outh process and the link to be used in user's browser:
https://secure.na1.adobesign.com/public/oauth/v2?redirect_uri=https://www.google.co.in&response_type=code&client_id=paste_your_client_id_here&scope=user_read:account
If any one using sandbox,
https://secure.na1.adobesignsandbox.com//public/oauth/v2?redirect_uri=https://www.google.co.in&response_type=code&client_id=paste_your_client_id_here&scope=user_read:account
Please ensure the correct environment identifier and shard. https://helpx.adobe.com/sign/using/identify-account-shard.html
https://helpx.adobe.com/sign/kb/unable-to-authorize-access-because-the-client-configuration-is-invalid-invalid-request-while-running-oauth-process.html
After pasting URL in browser and allowing the access to your API and getting code. Please use endpoint URL to get access token as below:
for developer account: https://api.na1.adobesign.com/oauth/v2/token
for sandbox account: https://api.na1.adobesignsandbox.com/oauth/v2/token
I keep getting this same OAuth error when trying to work with the github api. Sometimes it goes away but most of the time it stays. I have tried resetting my secret key, revoking all tokens, clearing safari cache but no luck. This is the error : error=redirect_uri_mismatch&error_description=The+redirect_uri+MUST+match+the+registered+callback+URL+for+this+application.&error_uri=https%3A%2F%2Fdeveloper.github.com%2Fv3%2Foauth%2F%23redirect-uri-mismatch
All the forums say to fix this error, remove the redirect_uri parameter of my request which I have done.
This is my request: https://github.com/login/oauth/authorize?client_id=myclientid&scope=user,public_repo
Everything shows up and when I click authorize it redirects me back to my application but instead of giving me the code it gives me the error.
Either put http instead of https in your Authorization callback URL
in your GitHub OAuth apps settings.
http://www.example.com/oauth/complete/github/
Another Option
settings.py
SOCIAL_AUTH_REDIRECT_IS_HTTPS = True
We have Google oauth2 working fine on our website. However, often Chrome users complaint about 400 Bad request and we were able to reproduce it now. Based on the investigation, it indeed looks like a bug on Google side:
It only happens with users who were authenticated earlier and logged-in with multiple accounts on GMail
It doesn't happen when the same user uses incognito window.
This problem is universal and not only with our website. At this moment, I am not able to login using google oauth2 on any website including StackOverflow. Stackoverflow site also gives the same 400 Bad request error and I have to use incognito.
No additional information is present along with 400 Bad Request Error
To further confirm, I just loaded https://accounts.google.com/o/oauth2/auth without any parameters and it also gave 400 Bad request. However, if I load it in incognito, it gives Error: invalid_request. So there is indeed different behavior.
So We suspected that the problem might be with cookies sent along with request since incognito window has no cookies. So we cleared all the cookies for domain accounts.google.com and problem magically solved. This confirms that Google side of code is not able to handle their own cookies.
We really need to solve this. Please help. Do let me know if you need any information.
This might be caused only for the clients that have multiple google accounts logged in as described here Google OAuth2 returns Bad Request when logged with multiple accounts.
It is not clear to me if is a google bug or a miss-use of the api. Anyway stackoverflow is affected as well.