I have been toying around with the twitter API over the last few days, but seem to be stuck at requesting a "request token". (flow A)
Over at the twitter api, I should be hitting the following end point (https://api.twitter.com/oauth/request_token) and on a successful request this should net me an oauth_token, oauth_token_secret and oauth_callback_confirmed (should match what I pass). I attempted to just use my private key, but this of course is failing. Is my understanding of how to generate this request wrong?
I believe my issue is the way I am generating the oauth_signature. Reading the documentation at twitter, everything seems straight forward until I need to generate signing key documented Here. It states that the signing key should be Consumer Secret & OAuth token secret, but to me this is a circular reference. The response, for this request, should contain the oauth_token_secret.
With this request an empty oauth_token_secret is expected. Signing key should be consumer_secret&, the trailing & must be included.
Relevant quote from https://www.rfc-editor.org/rfc/rfc5849#section-3.4.2:
An "&" character (ASCII code 38), which MUST be included
even when either secret is empty.
Related
Cheers everybody,
we have been deeply reading google documentation on exchanging access_token from google in order our (delphi)desktop application to SSO with google from server side. Here is the payload we send first look like:
https://accounts.google.com/o/oauth2/v2/auth?client_id=1000217514248-t1lojs6f8ed7l9ocrpbm98leahtum8n1.apps.googleusercontent.com&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&state=E1DF2FBA-0A66-4D69-B594-5EB8F7828AF7&scope=openid+profile&include_granted_scopes=true&code_challenge=C832DA50-E55A-499D-89B8-493BB4123C94&login_hint=test#Speelkriebel.be
Normally after this it redirects me to login in to our test user and after this according to the documentation we send a POST request to the end point token in order to get the access_token and refresh_token...: 'https://oauth2.googleapis.com/token
with the following parameters, the 'code' is generated we also send it as follow:
client_id=1000217514248-t1lojs6f8ed7l9ocrpbm98leahtum8n1.apps.googleusercontent.com
grant_type=authorization_code
client_secret=******
code= 4/1AY0e-g4GlavO38PI5Oo3vq04Pc4lMWN77et-02UiVWOsT-IyRQnU1lq19qo
redirect_uri = urn:ietf:wg:oauth:2.0:oob
The response is always
{
"error_description": "Missing code verifier.",
"error": "invalid_grant"
}
We have tried to send the client secret id also, Does it have to do with our code_challenge ? are the end points url and initial url okay? What are we missing? We are using CEF4Delphi as "browser like experience in order for the user to type in their google credentials. We have been reading this: https://developers.google.com/identity/protocols/oauth2/web-server#offline
We were also trying the playground :https://developers.google.com/oauthplayground/
we were sending the initial url in a chrome which generated a "code" and in the playground we inserted the code, and still got the same error of missing code verifier.
Thanks Guys
You seam to have URL encoded a lot of the values try not doing that. Also try using the basic call, before you start adding everything else. It should help you figure out which one of those extra parameters you are sending that's causing your issues.
https://accounts.google.com/o/oauth2/auth?client_id={clientid}&redirect_uri=urn:ietf:wg:oauth:2.0:oob&scope=profile&response_type=code
Also make sure that the client id is from an installed / other type client
This may also help Google 3 Legged OAuth2 Flow
For installed apps, the code challenge and verifier are parameters for enhancing the security of the OAuth flow through PKCE [1].
There is additional documentation about generating a code challenge and verifier here [2].
[1] https://www.rfc-editor.org/rfc/rfc7636
[2] https://developers.google.com/identity/protocols/oauth2/native-app#step1-code-verifier
As part of the OpenID Connect (OAuth2 for Login), my application is supposed to request an access token, given a one-time authorization code, via the endpoint https://www.googleapis.com/oauth2/v3/token. According to documentation, this request needs 5 parameters passed to it, client_id among them. That is exactly what my application does, using the Perl module Net::OAuth2.
Everything has been working fine for several months, but today I was notified that it stopped working. No updates were made to the application code nor the libraries used by it.
The message my application now receives from the server when calling the token endpoint is this, in a 400 error response:
OAuth 2 parameters can only have a single value: client_id
A Google search suggests nobody has ever seen this message before, or lived to tell the tale. There doesn't seem to be a general issue with Google's OpenID Connect (other services based on it are working flawlessly), and the imminent shutdown of the old login protocol doesn't seem relevant.
More testing: removing all parameters except client_id causes this error message:
Required parameter is missing: grant_type
Supplying only client_id and grant_type produces the original error message again.
Does anyone have an idea what's going on here?
Google changed this behavior few days ago, so any OAuth2 library using Basic Auth headers AND body request parameters will start to see messages like
OAuth 2 parameters can only have a single value: client_id
or
OAuth 2 parameters can only have a single value: client_secret
So, you must now do NOT use both (the Auth headers and body request parameters) at the same time to send credentials to Google.
And according RFC 6749, the preferable way to send credentials is through Auth headers (thanks #JanKrüger for alert me about this).
Got the same error. It seems the problem is that NET::OAuth2 sets the authorization header when exchanging authorization code for access token. If you remove this header everything works fine.
Check the get_access_token method in Net::OAuth2::Profile::WebServer module. The authorization header includes client_id:client_secret base64-encoded string. Apparently Google now treats this duplication as an error.
The right way of fixing this is to set the secrets_in_params parameter when creating Net::OAuth2::Profile::WebServer object. Look in the Net::OAuth2::Profile documentation for more details.
I'm busy with implementing reverse authentication on iOS. I'm making it on the base of this example and twitter documentation.
I'm trying to figure out whether the consumer secret is mandatory to perform STEP 1 from the docs (obtaining a special request token). The docs say:
As an example, consider a request with the following values signed with the consumer key JP3PyvG67rXRsnayOJOcQ and consmer secret ydC2yUbFaScbSlykO0PmrMjXFeLraSi3Q2HfTOlGxQM.
Seems like the secret is needed. But then it lists the parameters for the request:
oauth_consumer_key JP3PyvG67rXRsnayOJOcQ
oauth_nonce 1B7D865D-9E15-4ADD-8165-EF90D7A7D3D2
oauth_signature_method HMAC-SHA1
oauth_timestamp 1322697052
oauth_version 1.0
x_auth_mode reverse_auth
and there's no secret. and also no oath_signature. It then confirms my suspicion by the following:
These parameters should result in a signature base string that looks like this:
POST&https%3A%2F%2Fapi.twitter.com%2Foauth%2Frequest_token&
oauth_consumer_key%3DJP3PyvG67rXRsnayOJOcQ%26
oauth_nonce%3D1B7D865D-9E15-4ADD-8165-EF90D7A7D3D2%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1322697052%26
oauth_version%3D1.0%26
x_auth_mode%3Dreverse_auth
again, no secret and no oath_signature parameter. Then i look at the example app i have taken from the GitHub and see that it actually makes use of the secret. It makes some magic, mixes the secret with different strings, encrypts it and makes it into oauth_signature parameter which goes into the authorization header for its request. The complete authorisation header looks like this:
OAuth oauth_timestamp="1405695110", oauth_nonce="0C38A128-42B1-41D1-B31D-EBEBE8971470", oauth_version="1.0", oauth_consumer_key="u97hVQZtAcRbLWHv5CkONbaJ8", oauth_signature_method="HMAC-SHA1", oauth_signature="iuaqaN1MvFHyKMa95LFWXCxUfDM%3D"
The only difference between this and Twitter doc's example is that here is oauth_signature parameter (made from the secret) present. And the example works all right. I tried removing the secret when making the signature and received an error from Twitter.
So I am confused. The docs don't clearly state that the secret is required whereas the example uses it as its important part. So is it mandatory? And if not can you please explain how do I build a request without the secret?
I am having some issues with MapMyFitness API. MapMyFitness uses OAuth 1.0
I am able to successfully get a temporary Authorization token/temporary secret Token combination from calling 3.1/oauth/request_token
After that, I am able to successfully direct the user to the Authorization page and get a redirect callback with a authorization verifier.
After that, I am, unfortunately, getting errors when trying to call 3.1/oauth/access_token. (HTTP error 401)
First of all, MMF documentation (http://api.mapmyfitness.com/3.1/oauth/access_token?doc) states: Exchange a request token and an authorization verifier for an access token. However, the list of input arguments in the documentation contains no mention of oauth_verifier. Should oauth_verifier that I have received with the redirect callback be passed to access_token call as an argument?
Secondly, it appears to me that perhaps I am not creating the signature correctly. For the 3.1/oauth/request_token call the key to generate the signature is 'XXX&' where XXX is the Consumer Secret Key assigned to my app by MapMyFitness. This works fine. For the 3.1/oauth/access_token call, I am using 'XXX&YYY' as a signature key where XXX is the Consumer Secret Key assigned to my app by MapMyFitness and YYY is the temporary Secret Token returned to me by the server during the 3.1/oauth/request_token call. Is that correct?
I would greatly appreciate any suggestions.
OK, I got it working. First of all, oauth_verifier DOES need to be included as part of parameters. For some reason, Map My Fitness does not include it in its list of required parameters, but it has to be there. Secondly - very important - according to OAuth 1.0 documentation, all parameters need to be in alphabetical order when creating the signature - otherwise there will be a signature mismatch and you'll get HTTP 401 error. Once I sorted my parameters in alphabetical order, I was able to exchange temporary MapMyFitness credentials to permanent ones.
I'm using this code/guide another twitter oAuth cURL access token request that fails to test signing my request to the API. I'm still trying to go through step 1 of this
Note: the keys are just random, they're not real :)
when I try to make a request without oauth_callback I get a valid response from the api
https://api.twitter.com/oauth/request_token?oauth_consumer_key=nHb2kSQ2CD9MW1MdW5VeQ&oauth_nonce=1356902849&oauth_signature=MbvhwGiNPKQR0klUPx9fsmUtdJY%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1356902849&oauth_version=1.0
when I add the oauth_callback string (mandatory to let users sign with a redirect!) I get "Failed to validate oauth signature and token"
https://api.twitter.com/oauth/request_token?oauth_callback=http%3A%2F%2F127.0.0.1%2Ftest%2F&oauth_consumer_key=nHb2kSQ2CD9MW1MdW5VeQ&oauth_nonce=1356902915&oauth_signature=2WTaI9jXNBaDd7f8AqIe6y3%2Beno%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1356902915&oauth_version=1.0
I mean there's no difference between the two URLs, they both go through the same execution and they respect the signing method.
How to fix it?
yes I added http://127.0.0.1/test/ as callback url in the twitter app settings.
Thank you
Have you set up the callback url in the twitter application settings?
If you don't set that up, the api may fail.
Check it from here:
Also check that your time is in sync (use an NTP server); see: https://dev.twitter.com/discussions/1043
Agreed that twitter API is badly documented :)
Follow this rule:
If your oauth_callback does not contain any query string = Nothing funky is required.
If your oauth_callback has any query string parameters = URL Encode the query string parameters separately.
Hope this explains.
I solved the issue. The problem was that even though the callback URL was sent correctly using the querystring method or headers as you can see on the links, it was also double escaped when creating the signature from the basestring. Since the documentation is pretty bad regarding this I didn't think that you shouldn't double escape it as well like other oauth_* parameters (aka percentage encode the "&"s).