It looks like Twitter changed terminology over the years and did not update their docs appropriately, which leads to confusion (at least on my part).
According to https://dev.twitter.com/docs/auth/authorizing-request I need to use oauth_consumer_key and oauth_token.
At this time I want to access the account that is owned by the website that is making the request, so I am not trying to get a token for a website user, but instead use the tokens provided by Twitter for the Application.
In the Application details page, I have values for API key, API secret, Access token, and Access token secret
Can you tell me how these keys/secrets map to the oauth_consumer_key and oauth_token? And what are the other two used for?
Thanks!
OK, I figured it out.
It looks like Consumer maps to API and Access Token maps to OAuth Token, so to clarify:
oauth_consumer_key : API Key
oauth_token : Access Token
Consumer secret : API Secret
OAuth token secret : Access Token Secret
Related
I cannot understand what is the difference between API key, API key secret, Bearer Token, Access Token Access Secret. There is also Client ID and Client Secret which is something very confusing.
I wish to create a Twitter bot, but I find this very confusing. I have tried googling my question, and searching it up on youtube, but I have not found an answer that clears my question.
Admittedly the terms are a bit confusing;but these terms have the same meaning:
Consumer key = Customer key = Api key
Consumer secret = Customer secret = Api secret key
In general, tokens above and Bearer token represent the user that you are making the request on behalf of.
Access token and Access secret - they are Username and Password for your App.
And their usage:
Consumer key, Consumer secret, Access token, Access Secret (or only Access token and Access Secret depending on language and libraries you are using) - these are needed if your software make request to endpoints with POST method, that is if it tweets, replies to a tweet and etc.
If the software make request to endpoints with GET method then authenticating with Bearer Token is enough. Another use of Bearer Token is with Twitter API v2, which only accepts Bearer Token authentication if try to make requests to endpoints of this api.
For more detailed information Getting Access to Twitter API
If you want to simply read tweets, then Bearer Token is enough.
If you want to create tweets then you will need to use:
API Key
API Key Secret
Access Token
Access Token Secret
The client Id and client secret are not require.
There's a full articl here:
https://pythonhowtoprogram.com/how-to-build-a-twitter-bot-with-python-and-twitter-api-v2/
Lets say I have created my own application. We have react front end and RESTful API as backend and we are using Google OAuth for Authorization of our users. Front end is making calls to the APIs. Front end uses Authorization Code Flow of OAuth. After getting access token from Google OAuth server, front end uses this token to make calls to my backend.
Now Malicious user will get my API's URL, other information required for REST API from Chrome Network tab and can call directly to APIs with access token.
Questions:
How will my REST API know from where the request is coming?
Also how it will validate the access token?
Is it possible once User got all information about my REST API, it can call directly with fake access token?
I have look into the diagram for Authorization Code Flow. Below is the link.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-app-types
But how will web api validate the token?
Please guide me if I am lacking some information.
Google's OAuth server will issue your front-end a JSON Web Token (JWT). This token is singed by Google private key. Your API needs to:
Obtain Google's public key and
Verify the signature of the JWT.
If that is valid, the token originated from Google. If not, it didn't come from Google or was tampered with.
After this, your API needs to do a few additional checks:
Check the expiration time and see that it's not in the past. This can be found in the exp claim.
Check that the token is not only from Google but for your API. This can be done by looking at the aud (audience) claim and seeing that it's for you.
Check when the token was issued, and ensure that it's not in the future. The issuance time is in the iat claim.
Check that you should start using it already, and there wasn't some sort of embargo on the usage period. This will be indicated in the not-before claim (nbf).
Check that the type of token is an access token (as opposed to an ID token).
(You can find a longer more detailed description in this howto.)
If you do these things, you can be sure that Google issued the token and that it was intended for your API. It does not indicate to your API that the caller was your front-end. The reason is that the token is an "bearer token", meaning the token is bound only to the one that bears or presents it. To ensure that only your app provides the token, you need it to prove possession of a private key. This is not possible when using Google as your token issuer (to my knowledge).
My question is basically how do my rest api validate integrity of the token. I found the link: https://developers.google.com/identity/sign-in/android/backend-auth
I've seen these questions about using Postman in order to invoke Google's API with OAuth 2:
Using Postman to access OAuth 2.0 Google APIs
Could not obtain Google oAuth 2 token on POSTMan
and many more, but they all have client ID and client secret.
For the 'Save to Android Pay' API, all I got is a .p12 key and an issuer ID. I also have Service Account Email Address but defiantly no client id or secret. I think I also have the Auth URL but I'm not sure: https://www.googleapis.com/auth/wallet_object.issuer
Looking in the Save to Android Pay API, doesn't say anything about a client id so I'm really not sure how I'm supposed to obtain a token in POSTMAN with what I have.
So my question is: giving a .p12 key, an issuerId and a Service Account Email Address, What do I need to fill in POSTMAN OAuth 2 fields:
Token Name, Auth URL, Access Token URL, Client ID, Client Secret, Scope (Optional), Grant Type
To obtain OAuth 2.0 client credentials, you need to register an application to the Google API Console as specify in the basic steps and then you'll get a client ID and client secret.
I'm trying to understand what each string in the Oauth 1 scheme does.
As per my understanding, the consumer key and consumer secret are used to sign a request to the api, from the calling application, and the access_token and access_secret pair are used as a proxy for the user's login credentials.
Am I right in my understanding?
Not quite. The consumer key is a value that identifies the client application that is being used to access the user resources, and the access token is the value that provides the authorization to access those resources.
A combination of the consumer secret and token secret are used to sign the request which provides verification that the request is being sent by an authorized party.
You can read more about the definitions of the oauth 1.0a spec here.
I've been trying to implement 'Sign in with Twitter', but I'm stuck at trying to work out how to get an OAuth token secret for the user.
The Twitter API docs (here) say:
To start a sign in flow, your application must obtain a request token by sending a signed message to POST oauth/request_token
...
The body of the response will contain the oauth_token, oauth_token_secret, and oauth_callback_confirmed parameters
And the docs for creating a signature (here) say:
The value which identifies the account your application is acting on behalf of is called the oauth token secret. This value can be obtained in several ways, all of which are described at Obtaining access tokens.
And the 'obtaining access tokens' page links back to here, completing the circle.
How can I obtain a token secret if I need a token secret to sign the request to obtain the token secret? What the heck?
From the docs on creating a signature:
Note that there are some flows, such as when obtaining a request token,
where the token secret is not yet known. In this case, the signing key
should consist of the percent encoded consumer secret followed by an
ampersand character '&'.
You received a consumer secret when you registered for an API key. This is what you want to sign with to obtain a request token.
I would highly recommend looking into using a library which implements at least the oauth basics such as signing if not a Twitter API library, assuming one is available for your language of choice.