Twitter API Question posted in
The official Twitter API documentation can be found here.

Is it a security vulnerability to put TWITTER_CONSUMER_KEY / SECRET in client for oAuth1 Twitter Login? – Twitter API

All of the React Native Twitter Login Clients that I’m finding seem to be hard-coding the TWITTER_CONSUMER_KEY and TWITTER_CONSUMER_SECRET into the the client code, rather than relying on a server to generate tokens and/or a twitter redirect URL.

  • Is this safe? (e.g. couldn’t a consumer then DOS the API with the TWITTER_CONSUMER_KEY, causing the app to be rate limited?)
  • Is this the correct way to do it?
  • Is there a better / more secure way?

According to twitter’s documentation, it seems like this is NOT the correct way to do this:
“In the event that you believe that your API keys has been exposed, you should regenerate your API keys by following these steps” – Authentication best practices

Examples which specify that the consumer key/secret should be hardcoded:

Related questions:

Tags:

2

Answers


  1. 0

    Is it a security vulnerability

    Yes.

    Your app can be rate limited or flagged as malware/spam etc.

    Is there a better / more secure way?

    Basically only to have your own site auth (oauth2) done correctly and proxy specific requests from your clients, after validation or a simplified locked down site API that is then translated to the Twitter API.

    Why is this, Twitter app-only auth supports OAuth2, allows a secure negotiated handshake and then requests made using a Bearer token. In this mode you can make requests on behalf of your App, but without a logged in user. So can’t post tweets or see private accounts or read DMs.

    For user-auth, Twitter only support OAuth1 and both the App and User are authenticated, but using a model that assumed plaintext http, so can’t share a single token. Every single request needs to be made using consumer key/secret and signing the request. So there isn’t a way to do this from a javascript client safely.

    Login or Signup to reply.
  2. 0

    Is this safe?

    Absolutely not. A bad actor can get users to authenticate via Twitter to receive their token credentials and then use your app’s consumer key/secret (which would be available in plain text) to masquerade as your app to do all kinds of nasty stuff.

    Is this the correct way to do it?

    Given the security vulnerability described above, no.

    Is there a better / more secure way?

    I’m currently in the process of trying to figure out how to securely achieve authentication with Twitter. This involved a lot of reading, but it appears as though it’s simply not possible without your own backend. I’ll try and explain why:

    1. Your goal is to receive the user’s email/Twitter-ID
    2. To achieve (1), you need to send a request to the GET account/verify_credentials endpoint (https://developer.twitter.com/en/docs/twitter-api/v1/accounts-and-users/manage-account-settings/api-reference/get-account-verify_credentials).
    3. To do (2), you need to provide an authorisation header, which is constructed out of several items, including the user’s OAuth tokens as well as your app’s consumer key/secret. More info here: https://developer.twitter.com/en/docs/authentication/oauth-1-0a/authorizing-a-request.
    4. You retrieve the user’s OAuth tokens using the 3-legged OAuth flow
      described here: https://developer.twitter.com/en/docs/authentication/oauth-1-0a/obtaining-user-access-tokens. The first step of this process is to send a POST request to the oauth/request_token endpoint (https://developer.twitter.com/en/docs/authentication/api-reference/request_token).
      This endpoint itself requires an authorisation header constructed using
      your app’s consumer key/secret.

    Obviously you can’t perform step (4) because that implies you would have your consumer secret available in the client; even if it’s not hardcoded, it would have to be in memory at runtime, at some point

    Once you have your own backend service, one option would be for your client app to open a browser and direct to an endpoint (let’s call it /auth/twitter) on this service which will perform all the steps mentioned above.

    This same service could also implement another endpoint (/auth/twitter/token) which handles requests to the callback URL, which you set in your Twitter app settings. This callback URL is used as part of the same 3-legged flow. This endpoint would have all the information needed to then go ahead and retrieve the user’s email/Twitter-ID.

    Finally, /auth/twitter/token can redirect to a custom URL which your client app would need to handle as part of its URL schemes. It can include enough information by way of parameters for your app to continue as needed post-auth.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search