Scribe is an excellent choice. The author is very responsive to issues as
well.

So, the "one access token" flow is essentially starting OAuth from the point
of having completed the "Exchange Request Token for an Access Token" flow --
now you have an oauth_token and oauth_token_secret that comprise your
"access token" and with it, you can make all the authenticated REST API
calls you know and love, signing the request with these credentials. With a
single access token use case, you don't implement any of the request_token,
authorize, or get access_token steps.

As for multiple accounts -- that's really all up to you. To associate more
accounts with the same application, you'll need to build out more of the
OAuth flow -- the "my access token" feature we offer will only give you an
access token for the user who owns the application. If you want to support
more accounts, simply push them through the request_token -> authorize ->
access_token flow, and you'll end up with more access tokens, which you'll
store and associate with the specific user, shifting contexts as needed (or
authorized) in your application.

Hope this helps.

Taylor

On Wed, Jun 16, 2010 at 1:11 PM, Rob <robert-h...@comcast.net> wrote:

>
> I'm working (more or less) in Java. I'm planning to start picking
> through the Scribe library to see the flow.
>
>
> The flow (http://dev.twitter.com/images/dev/oauth_diagram.png) makes
> sense.  What I'm having difficulty with is mapping the pieces of that
> diagram to the single token solution.  What steps from the diagram
> (and in what sequence) apply to the STS?
>
> Also, in the case of server-side accesses, what is the mapping of
> Twitter "application registrations" to Twitter IDs?  One app's
> registration can access multiple Twitter IDs (concurrently) or is it
> one app/reg per TwID?
>
>

Reply via email to