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
