Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?)

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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