There is a use case that sort of sucks when you don't force the user
to authenticate each time, and thats when a your application supports
multiple twitter accounts. Its nice to shortcut authenticating because
it removes a step for the end user, but it sucks when you are trying
to associate with multiple accounts.
It would be nice if we could pass a flag to force login to show, or
pass in an expected username and if its not the same as what twitter
has for their session cookie, it invalidates and forces a login or
something.
Not sure if something like this exists already or anyone has ran into
this issue and figured out a work around.
Zac Bowling
Zac, you should just use the /oauth/authorize link instead. the
/oauth/authenticate link is what will do the auto-redirect.
-Chad
It's really not directly related to "twitter sign-on" directly but
with OAuth authentication in general that doesn't force the user to
authenticate each time.
The problem is with all OAuth providers that shortcut the process of
associating and granting user permissions by bypassing the login
screen if they are already logged into that site (have a session
cookie already or something).
When our client or service handles multiple accounts the OAuth
provider has for just a single user on our-side.
What happens is that when a user on a service or client on our side
wants to connect and authenticate with multiple accounts. For each
link they create on their account on ourside, we will redirect them
back to twitter or OAuth provider to grant us permissions. The problem
is that they are automatically logged in using their session on that
site, so the permissions they are granting us are for that same user
that they probably already set up previously.
Does that make sense?
Zac Bowling
One issue I have is that the oauth/authenticate method expects an
oauth_token as part of the request. Until we've authenticated the user,
how do we _know_ what the user's oauth_token should be?
Are we supposed to request and use a new unauthorized token every time
we present the "sign in with Twitter" button in our third-party
application? (You can smell why this idea stinks, right?)
Also, the redirect to the callback URL has no signature. What stops an
attacker from brute-force attacking an OAuth consumer, iterating through
posisble tokens? Simply the large search space of valid OAuth tokens?
Even if it's only "possible in theory" ... some teenager with nothing
better to do is going to eventually turn that theory into practice.
What would be ideal is a method that we can link a user to that follows
the oauth/authenticate 4-step decision tree described on the wiki but
requires only a callback URL. When Twitter sends the user back via the
callback URL, it should include a valid OAuth access token, Twitter user
ID and screen name, and signature.
Then, another method like oauth/token where a signed request with the
OAuth token can be made that returns the token secret.
Possible?
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
One issue I have is that the oauth/authenticate method expects an oauth_token as part of the request. Until we've authenticated the user, how do we _know_ what the user's oauth_token should be?
On 4/16/09 12:55 PM, Doug Williams wrote:
Related: More OAuth documentation is to come throughout the day so
some of the links will be broken. It's a glaring omission in the
documentation.
Let's use this thread to fill the holes people find while implementing
Sign in with Twitter for the time being.
Are we supposed to request and use a new unauthorized token every time we present the "sign in with Twitter" button in our third-party application? (You can smell why this idea stinks, right?)
Also, the redirect to the callback URL has no signature. What stops an attacker from brute-force attacking an OAuth consumer, iterating through posisble tokens? Simply the large search space of valid OAuth tokens? Even if it's only "possible in theory" ... some teenager with nothing better to do is going to eventually turn that theory into practice.
What would be ideal is a method that we can link a user to that follows the oauth/authenticate 4-step decision tree described on the wiki but requires only a callback URL. When Twitter sends the user back via the callback URL, it should include a valid OAuth access token, Twitter user ID and screen name, and signature.
Then, another method like oauth/token where a signed request with the OAuth token can be made that returns the token secret.
Possible?
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
How does this prevent (b)? If I know a third-party application's
callback URL, I can currently brute-force a user's oauth_token, assisted
by a basic session-fixation attack. The callback URL isn't signed by
Twitter.
Perhaps oauth/authenticate would require a signed request that doesn't
include/require oauth_token. Upon successful process flow, Twitter
would send the user back using a signed callback URL that includes the
user's oauth_token. Then, all we would need is a method to retrieve the
oauth_token_secret for that oauth_token.
This would enable third-party applications to completely use Twitter for
its authentication, in lieu of OpenID.
How do you know which oauth_token to supply to Twitter when making the
request? You maintain your own username/password database for your
users that you then associate to their oauth_token's?
My hope was that we could leverage Twitter to authenticate (!) users so
that we third-party app. developers wouldn't need to authenticate users
separately with our own user/password scheme.
One can dream, right? :-)
I just tried out the oauth/authenticate - I supplied a RequestToken and
it redirected back to my callback URL with an AccessToken ... but,
what's the token secret for this AccessToken? I only know the secret
for the RequestToken I sent it ... Is the token secret the same for the
AccessToken I get back?
I'm going to assume so, although the OAuth spec. suggests that when
obtaining an AccessToken, both the oauth_token and oauth_token_secret
are returned, and I imagine it's desirable to have a different secret
for this different token, although obviously there's nothing that
prohibits reusing the same secret.
In order to make 'Sign in with Twitter' secure we do indeed now
return the request token, and you can then exchange that for an access
token. There is a ticket in place [1] to update the documentation to
match.
Thanks;
– Matt Sanford / @mzsanford
Twitter Dev
[1] - http://code.google.com/p/twitter-api/issues/detail?id=488