Hi,
We're always working on making the documentation better and I can see how
some of these aspects of OAuth would be difficult to grok when you're used
to other means.
One way I like to think about this is: Think of your HTTP request as an
envelope. The URL is the address. Your consumer key and access token is the
sender's address. Your POST body is inside the envelope. And the postage,
ink, bar codes and such are your HTTP headers, including your OAuth
Authorization to send this letter to the recipient.
Specific Answers below:
1. Can an application have multiple access tokens open at the same
time, for different accounts? Or is the previous access token
invalidated as soon as a new user is authorized?
Absolutely. Your application is its own entity. You could have 1 user. You
could have 5 users. You could have millions. Each of those users in your
system would have an access token associated with them (which is actually
two fields you would store, an oauth_token and oauth_token_secret). The
only time access tokens expire in our OAuth implementation is when the user
manually severs the connection in their settings page, or if you re-prompt
them for access by invoking the OAuth flow again, which gives them the
opportunity to deny the request. The user is always in control of whether
your application can act on their behalf.
2. If it can have multiple access tokens, are the Token and Token
Secret the only information needed to authorize a request for a
certain user?
They're all you need to identify the user, yes. But you still must sign the
request using your consumer secret (API secret) as per the OAuth
specification.
3. When using the authorization headers and generating the base
signature, are all of the authorization parameters (excluding
oauth_signature) merged with the request parameters?
If you use authorization headers, you don't include any OAuth-related query
parameters on the query string. I recommend using headers exclusively, as
query-string based OAuth is more difficult to debug and it's better to
separate concerns: you're requesting a resource, and the OAuth parameters
don't have anything to do with the resource identified in the URL. The
authorization HTTP header is more appropriate.
While you don't include OAuth parameters on the query string, you DO need to
still include any query parameters that are particular to the resource you
are requesting (like page, count, etc.) in addition to putting them into the
signature base string construction algorithm. If you have POST parameters,
they still need to be sent in the POST body. Nothing really changes here in
the way you use the API as far as the basics of using REST go.
Taylor
