I'm trying to exchange an OAuth 2.0 Authorization Code for an Access Token using Google's OAuth Playground tool. So, I get to step 2 and there it shows the HTTP POST request it will be sending out to MY_SERVER (I obfuscated the exact IP address for security reasons).
To me this looks correct and if I use a POST tool with exactly this request, it does arrive on my server. Launching it from the Playground, it doesn't arrive on my web server (nothing in the logs).
Does anybody have an idea what might be going wrong?
THIS POST
POST /tb/html/token/ HTTP/1.1
Host: MY_SERVER.COM
Content-length: 170
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
code=Splxl0576dGF6567gFG&redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&client_id=jarne&scope=&client_secret=some_secret&grant_type=authorization_code
RESULTS IN
HTTP/1.1 400 Bad Request
Content-length: 105
Content-type: text/plain
An error occured while connecting to the server: Unable to fetch URL: http://MY_SERVER.COM/tb/html/token/
Related
I tried to perform this request but I get errors:
1. { "error": "invalid_client", "error_description": "The OAuth client was not found." }
After I request it again:
2. 405. That’s an error.
The request method omPOST is inappropriate for the URL /oauth2/v4/token. That’s all we know.
Details:
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-length: 208
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
client_secret=MYSECRET&grant_type=refresh_token&refresh_token=MYTOKEN&client_id=MYCLIENTID
EDIT:
I was sending the request to an invalid endpoint, making it unavaiable for me to receive the expected data. I was able to fix it by following the steps in the google docs: https://developers.google.com/identity/protocols/OAuth2WebServer
The error indicates your client ID is wrong. Please make sure it's the client ID from the Google API console (console.developers.google.com) and it matches the Client Secret. The refresh token should also be one issued to the original client ID.
We are building a smart home app using actions on google for the google home. Our app requires signing into our system to be able to access the users devices so they can control them using their voice over google home. Our user backend is built using AWS Cognito. We are using API.AI as part of the Google Home app.
I have configured the Cognito OAUTH2 endpoint and the actions on google app to work with each other using the auth code flow and varying scope's but there is something I am missing. When I attempt to link the user account to the Google Home app i get redirected to our login page. After filling out the user details I'm returned to the Google Home 'Discover' tab but there is a message across the bottom that states: ‘Bad response from IdP in Auth Code Exchange’.
I also have tried it using Google's OAUTH2 playground. It seems that when using that I am able to get the code from our OATUH server, but when trying to exchange the code for a token i get the following error:
HTTP/1.1 400 Bad Request
Strict-transport-security: max-age=31536000 ; includeSubDomains
X-content-type-options: nosniff
X-application-context: application:prod:8443
Transfer-encoding: chunked
Set-cookie: XSRF-TOKEN=35f58337-76f4-4993-a0c9-93429134ea42; Path=/; Secure; HttpOnly
Expires: 0
Server: Server
Connection: keep-alive
X-amz-request-id: 284d862e-b021-4079-b5f5-3cbce675983c
X-xss-protection: 1; mode=block
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 23 Aug 2017 13:51:42 GMT
X-frame-options: DENY
Content-type: application/json;charset=UTF-8
{
"error": "invalid_client"
}
I have checked and rechecked the client ID and client secret etc and cannot find any errors.
Does anyone have any idea how I might fix this problem?
Thanks in advance
ok，may be i know the reason.....If you use aws cognito ...
According to this doc (http://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html)
Authorization
If the client was issued a secret, the client must pass its client_id and client_secret in the authorization header through Basic HTTP authorization. The secret is Basic Base64Encode(client_id:client_secret).
they need put client and client sectet in header ...
Then I use aws http proxy caught the request of google progress .
Method request headers: {X-Cloud-Trace-Context=d7b6b9b8239965baf69acab659e80a01/13879251242019662389, CloudFront-Viewer-Country=US, CloudFront-Forwarded-Proto=https, CloudFront-Is-Tablet-Viewer=false, CloudFront-Is-Mobile-Viewer=false, User-Agent=google-oauth-playground AppEngine-Google; (+http://code.google.com/appengine; appid: s~oauth2playground), X-Forwarded-Proto=https, CloudFront-Is-SmartTV-Viewer=false, Host=en75z5h2rb.execute-api.us-east-1.amazonaws.com, Accept-Encoding=gzip, deflate, X-Forwarded-Port=443, X-Amzn-Trace-Id=Root=1-5a0fcef2-09197cd86a625ad47d78f0b7, Via=1.1 d63a8908759a2f4775b3f672ebf823cc.cloudfront.net (CloudFront), X-Amz-Cf-Id=nFdLK97vAS5HvmpNYkPpbUMOB4bCaM6pScHWTAReAnonLg1gXF7hSg==, X-Forwarded-For=107.178.195.199, 54.182.238.53, content-type=application/x-www-form-urlencoded, CloudFront-Is-Desktop-Viewer=true}
There are no Authorization in request header. So the Cognito will return back
"error": "invalid_client"
According this OAUTH2.0 spec (https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1)
I have already ask AWS support. They said:
Thanks for contacting AWS Support and providing us with detailed references. I would be happy to assist with your question regarding Cognito supporting client credentials in the request-body.
After reading through the OAUTH2.0 Standards RFC 6749 [0], It looks like including the client credentials in the request-body is not recommended. Here's an excerpt on the spec:
"Including the client credentials in the request-body using the two parameters is not recommended and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes)."
HTTP digest authentication no longer works in our app since iOS 10 due to wrong nonce-count in Authorization: Digest header generated by NSURLSession.
The same code works in iOS 9, but fail to auth in iOS 10
Create a POST request with NSURLRequest
Fire it with NSURLSession
Handle NSURLAuthenticationMethodHTTPDigest in urlSession(_:didReceive:completionHandler:) delegate
The server responds with a 401 and qop="auth" string as expected
The app requests again with the Authorization: Digest header set.
According to RFC2617:
nonce-count
This MUST be specified if a qop directive is sent (see above), and
MUST NOT be specified if the server did not send a qop directive in
the WWW-Authenticate header field. The nc-value is the hexadecimal
count of the number of requests (including the current request)
that the client has sent with the nonce value in this request. For
example, in the first request sent in response to a given nonce
value, the client sends "nc=00000001". The purpose of this
directive is to allow the server to detect request replays by
maintaining its own copy of this count - if the same nc-value is
seen twice, then the request is a replay. See the description
below of the construction of the request-digest value.
However, the nonce-count start at "nc=00000002" even for the first request in iOS 10, which cause the server to reject it.
Expect server response 200 OK
iOS 9 & Before:
POST /Tunnel/Message.aspx HTTP/1.1
Host: 172.18.70.12:3454
Accept: */*
Content-Type: application/xml
User-Agent: iViewer/1 CFNetwork/758.5.3 Darwin/15.6.0
Connection: keep-alive
Cookie:
AuthType: digest
Accept-Language: zh-tw
Content-Length: 69
Accept-Encoding: gzip, deflate
Authorization: Digest username="admin", realm="ND8422P",
nonce="cc17a78cdd96d54e012eadefe7d13d82", uri="/Tunnel/Message.aspx",
response="51587db4bcf6eeece68c4ec21108f170",
cnonce="47b8df8a980f280038834b7817250e90", nc=00000001, qop="auth"
<?xml version="1.0" encoding="UTF-8"?><GetServerInfo></GetServerInfo>
HTTP/1.0 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/xml
Content-Length: 1127
iOS 10:
POST /Tunnel/Message.aspx HTTP/1.1
Host: 172.18.70.12:3454
Accept: */*
Content-Type: application/xml
User-Agent: iViewer/1 CFNetwork/808.0.2 Darwin/16.0.0
Connection: keep-alive
Cookie:
AuthType: digest
Accept-Language: en-us
Content-Length: 69
Accept-Encoding: gzip, deflate
Authorization: Digest username="admin", realm="ND8422P",
nonce="4b8bf8549da0c3010f031472e95f387d", uri="/Tunnel/Message.aspx",
response="91cf44bc0aadf2f743164d03b5c708c7",
cnonce="b5f9e6c69e19c1b396298d68f2aefe7e", nc=00000002, qop="auth"
<?xml version="1.0" encoding="UTF-8"?><GetServerInfo></GetServerInfo>
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest qop="auth", realm="ND8422P", nonce="8e8b0538bb08876ac4d8203f1d14e9ac"
CSeq: 0
Is anyone facing the same issue?
The only related post I could find is:
Apple Developer Forums : Problem of the digest authentication, but no further information.
How do you fix it or get workaround on client app side without asking server side to ignore the wrong nonce-count?
Thanks.
Apple Developer Technical Support confirm that is a bug of iOS 10.
Hope it will be fixed soon.
Thank you for contacting Apple Developer Technical Support (DTS).
We believe this issue is a bug. Please file a bug report using the Bug Reporter tool https://developer.apple.com/bug-reporting/.
Update:
Apple fixed this issue in iOS 10.2 Beta 3
Chances are, the OS is sending a HEAD request first, and your server-side code isn't getting it. I would try running Charles Proxy to verify that this is what's happening.
That said, skipping a nonce count is not inherently an indication of any sort of attack. It could occur even in iOS 9 if a request got lost somehow (e.g. a network error). What's important is to ensure that the count doesn't go backwards. So I would argue that your server code is buggy and should not be rejecting that to begin with.
We have the same problem in our company as described here:
Cordova app can't connect with Dynamics NAV Web-Service (ODATA) after update to iOS 10
We can reproduce the issue both in our App and the Safari Browser with iOS 10 devices. There does not seem to be a simple client side workaround. We opened a Bug Report with Apple.
In our case the problem was solved with the 10.2 Beta release.
I am trying to use a custom java application of mine to upload videos to my youtube account via an access limited device like a Raspberry pi running as a server.
For this I am using the Google Oauth 2.0 for limited input device as a reference.
Here I am facing following problem:
After getting the Device code via following similar call (Step 2 from the link):
POST /o/oauth2/device/code HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
client_id=1084945748469-eg34imk572gdhu83gj5p0an9fut6urp5.apps.googleusercontent.com&
scope=https://www.googleapis.com/auth/youtube
Google Oauth server responds with 'user_code' and 'verification_url' (Step 3 from the link):
{ "device_code" : "4/L9fTtLrhY96442SEuf1Rl3KLFg3y", "user_code" :
"a9xfwk9c", "verification_url" : "http://www.google.com/device",
"expires_in" : "1800" "interval" : 5, }
Now I am giving the requisite permission by opening the url as responded by google server.
Finally I am trying to get the access token from Google server (Step 4 from the link) by posting similar request:
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
client_id=1084945748469-eg34imk572gdhu83gj5p0an9fut6urp5.apps.googleusercontent.com&
client_secret=hDBmMRhz7eJRsM9Z2q1oFBSem&
code=4/YMSlR3fSCC1NtUh073DuZKTJJ3ss&
grant_type=http://oauth.net/grant_type/device/1.0
but instead of getting the 'access_token' as response I am getting the following :
Status Code:400 Response: { "error" : "invalid_request",
"error_description" : "Required parameter is missing: grant_type" }
Note : With or without url encoding, my problem stays the same.
Can someone please help me as to whether it's the Google Oauth 2.0 api is buggy or my request is faulty?
***************************************UPDATE*************************************
I tried the same steps with some alternative tools instead of my custom java application, so I tried Fiddler and curl, the surprise is as follows:
All of the calls worked right as mentioned by Google Oauth 2.0 for limited input device for curl.
Same issue was observed with Fiddler as was with my custom java app.
I am still unable to figure out the difference yet, still need help.
************UPDATE#2**************
Fiddler request:
(url encoded, obscured client secret)
(One can get oauth credentials (client_id and client_secret) by following this)
POST HTTP/1.1
https://accounts.google.com/o/oauth2/token?client_id=308065994473-ur9dd7003ajs6mvr5s4kqnugr6j8tsf2.apps.googleusercontent.com&client_secret=XXXXXXXXXXXXXXX&code=4%2FWR-qiTquqB0e4-0LCy0-7rZ2kkE2&grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fdevice%2F1.0
Content-Type: application/x-www-form-urlencoded
(non url encoded, obscured client secret)
POST HTTP/1.1
https://accounts.google.com/o/oauth2/token?client_id=308065994473-ur9dd7003ajs6mvr5s4kqnugr6j8tsf2.apps.googleusercontent.com&client_secret=XXXXXXXXXXXXXX&code=4/WR-qiTquqB0e4-0LCy0-7rZ2kkE2&grant_type=http://oauth.net/grant_type/device/1.0
Java code project is available at (maven project, check the test case for the Oauth calls):
https://docs.google.com/file/d/0B8ltWBtPF-DVMDZFNHNMZXpCQlk
The value is wrong, you should use grant_type=authorization_code as this says.
I try the guide here: Path Developers Docs
I can get access token from Path API.
But I can not send post photo request "POST /1/moment/photo".
Does anyone can do it?
I used gtw-oauth2 to get access token from Path API.
If you see the request format
POST /oauth2/access_token HTTP/1.1
Host: partner.path.com
Content-Type: application/x-www-form-urlencoded
Content-Length: <LENGTH>
grant_type=authorization_code&client_id=CLIENT&client_secret=SECRET&code=CODE
Content-Length line is not required, in getting permanent access token
code=CODE - was very confusing, and i see you can get temporary access token, but can't get permanent access token, in this line, capital CODE MUST BE REPLACED WITH TEMPORARY ACCESS TOKEN
don't change grant_type=authorization_code only
I think this will help you a lot
POST /oauth2/access_token HTTP/1.1
Host: partner.path.com
Content-Type: application/x-www-form-urlencoded
Content-Length:
grant_type=authorization_code&client_id=CLIENT&client_secret=SECRET&code=CODE