I noticed that if you have a 3rd-party Twitter app, you get an access token, and an access token secret, to communicate with Twitter.

Why are there two codes? Shouldn't one be enough?

Does this mean every 3rd-party app needs to have their own server that adds the token secret to the request? (Because if it were stored in the app itself, it could be decompiled and the secret revealed?)


One provides the identity, the other provides authentication. Generally, the idea is that the identity can be given out to clients of the third party, but the secret is used for communication between the third party and the server. The access token allows them to know which account it is associated with. It's not really any different from having a username and a password. I can tell you to send bob@mail.com an e-mail without you knowing Bob's password. I'm not sure if this is specifically how Twitter handles it, but it's a fairly common situation for the application to have an identifier and a secret.


It is part of OAuth or OAuth-like authn/authz protocols. The secret is only meant to be presented server-to-server, while the token can be routed through the user's agent (browser). The token can also have a certain scope and duration associated with it.

As the answer above also describes, a Twitter token can be handed to your app to query twitter on behalf of a user that is using your app.

There are other flows of OAuth that are very similar to userid/password, but still maintain this paradigm.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.