Sign in with Twitter
Doug Williams
This is the perfect tool for web applications wanting to offer users the ability to sign in with a Twitter account and a single mouse click. We want to see it in the wild so please let us know if you roll this out in your application.
Thanks,
Doug Williams
Twitter API Support
http://twitter.com/dougw
Doug Williams
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.
Cheers,
Zac Bowling
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
Ivan Kirigin
twitter accounts.
It should be one-to-many. Signing in with any of their twitter
accounts can sign in that user.
Let me know if that doesn't address your problem.
Ivan
http://tipjoy.com
On Apr 16, 1:18 pm, Zac Bowling <zbowl...@gmail.com> wrote:
> Hi Doug,
>
> 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
>
Chad Etzel
accounts authenticated.
Zac, you should just use the /oauth/authorize link instead. the
/oauth/authenticate link is what will do the auto-redirect.
-Chad
Zac Bowling
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
Abraham Williams
1) Authorize that always displays prompt on Twitter.
2) Authenticate that shows nothing if already signed in and authorized.
Use them based on your needs.
Something to keep in mind that OAuth is not designed for identity authentication. It is designed for data authorization. Yes it can and is used as such but it is a little bit of a hack.
Abraham
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
Dossy Shiobara
> 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.
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)
Matt Sanford
Abraham Williams
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.
I'm not quite sure what you mean by this. Oauth/authenticate works pretty much exactly the same as oauth/authorize but uses a different path and may not require any action by the user if they have previously authorized.
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)
Dossy Shiobara
> The initial token required is a RequestToken rather than an AccessToken.
> Making the request for the RequestToken requires you know the consumer
> key/secret and (a) let's us know what application this is for
> (callback_url alone would not) and (b) prevent the token-shooting method
> you described.
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.
Dossy Shiobara
> I'm not quite sure what you mean by this. Oauth/authenticate works
> pretty much exactly the same as oauth/authorize but uses a different
> path and may not require any action by the user if they have previously
> authorized.
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? :-)
Doug Williams
Matt and I agree there is value here. I've opened Issue 469 [1] to track this enhancement.
1. http://code.google.com/p/twitter-api/issues/detail?id=469
Ahmed R
users will only have to face the question of "Deny or Allow" access
only once.
The only problem I foresee is if multiple users use the same computer.
This way if USERA is already signed in to Twitter and USERB attempts
to log into my site, USERB might not pay too much attention and end up
using USERA's account. Ofcourse I can solve this by making it so
obvious on my site who is signed in. But then USERB would have to go
back to Twitter sign out USERA , then sign in to Twitter, go back to
my site and click the log in button on my site.
The ideal solution for me is when a user tries to sign in through my
app, they should be directed to a new authorization URL that asks the
question:
"continue to sign in as USERA or sign in with a different account?"
They click continue and are sent to the call back URL.
I know that this defeats the purpose of one-click log in. But it helps
in solving the problem of someone inadvertently using someone else's
account
Plus asking someone to "continue or sign in with a different user"is a
much softer question then "Deny or Allow access?" which sounds like a
much more critical question.
I still like the change and will begin using it, however if there was
the option of what I describe above, then I would use that.
Also thanks for making it so simple to adopt the new flow!
On Apr 16, 10:45 am, Ivan Kirigin <ivan.kiri...@gmail.com> wrote:
> Zac, this can be solved just be properly modeling user accounts and
> twitter accounts.
>
> It should be one-to-many. Signing in with any of their twitter
> accounts can sign in that user.
>
> Let me know if that doesn't address your problem.
>
Dossy Shiobara
> AccessToken. Making the request for the RequestToken requires you know
> the consumer key/secret and (a) let's us know what application this is
> for (callback_url alone would not) and (b) prevent the token-shooting
> method you described.
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.
Allen Tom
> change to the normal Twitter OAuth workflow and is documented here:
>
> http://apiwiki.twitter.com/Sign-in-with-Twitter
>
> This is the perfect tool for web applications wanting to offer users the
> ability to sign in with a Twitter account and a single mouse click. We want
> to see it in the wild so please let us know if you roll this out in your
> application.
>
Signing into websites using your Twitter account is an awesome idea,
Twitter accounts would make fantastic portable identities that can be
used to sign into 3rd party sites. Most sites using using Facebook
Connect or OpenID really just want your profile, follower graph, and
the ability to receive viral referral traffic by writing to your
activity stream.
OAuth is great for 3rd party applications that are built on top of
Twitter, however, I'm not sure if it's appropriate to use OAuth token
for Signing In to a website, because it allows that site to spam your
followers by tweeting on your behalf. Using OpenID is safer for Sign-
in, because OpenID would allow Twitter users to verify their Twitter
identity, and share their Twitter Profile and Follower Graph (by
scraping the microformats on the Twitter Profile Page), without having
to authorize access to their Twitter account. If Twitter users sign in
with OpenID, 3rd party sites could still generate viral referral
traffic by giving users a UI to preview and approve the tweet, by
opening a modal dialog or popup that reuses the user's twitter browser
session to tweet.
Allen
Matt Sanford
Doug Williams
OAuth is the third-party authorization protocol that we have decided to embrace. You can search the group's archives [1] for past discussion on OpenID and the Twitter API.
1. http://groups.google.com/group/twitter-development-talk/search?group=twitter-development-talk&q=openid&qt_g=Search+this+group
djMax
errors back. Was working ok 15 minutes ago.
Abraham Williams
John Kristian
merely deliver a user's ID and screen_name to a application, not to
authorize the application to access Twitter on the user's behalf. Is
that so?
A suggestion: treat the user ID and screen_name as a resource that's
protected by OAuth. Define /oauth/authenticate as the place a user
authorizes an application to get the ID and screen_name.
So, the flow would go like this:
1. The application GETs a request token from /oauth/request_token.
2. The application redirects the user's browser to /oauth/
authenticate.
3. The user authenticates and/or gives permission, if needed.
4. Twitter redirects the browser to the application callback.
5. The application GETs an access token from /oauth/access_token.
6. The application GETs the user ID and screen name from /account/
verify_credentials or something similar.
No sensitive data are passed from Twitter via browser redirects to the
application. The application may use HTTPS to secure its requests to
twitter.com/oauth.
John Kristian
authenticating, Twitter redirects back to my consumer with a different
oauth_token than the one I sent to initiate authentication. Twitter
APIs don't accept either token. Sending the original request token
to /oauth/access_token elicits HTTP 401 with an XML error "Invalid /
expired Token". Sending the second callback token elicits HTTP 500
Internal Server Error with an HTML body entitled "Twitter / Error".
When either token is used as an access token, Twitter responds with
401. The original request token elicits an XML error "Invalid /
expired Token"; the second token elicits "Failed to validate oauth
signature or token".
For signing I used the token secret associated with the original
request token. The user has already given permission to this
consumer.
Help?
Abraham Williams
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Matt Sanford
John Kristian
never authorize. That is, they don't ask for permission to access
Twitter on the user's behalf. Such an application would never direct
a user to /oauth/authorize, and thus would never get a token secret
from the authorization flow. Nonetheless, it might need a secure way
to get the user's ID and name.
Rore
On Apr 17, 4:31 pm, Matt Sanford <m...@twitter.com> wrote:
> Hi all,
>
> This behavior (i.e. which token is returned) is likely to change
> soon. Once again, stay tuned for updates.
>
> — Matt
>
> On Apr 17, 2009, at 01:02 AM, Abraham Williams wrote:
>
> > The oauth_token returned from oauth/authenticate is the key from the
> > users access tokens. as long as you store the access tokens you can
> > match the returned oauth_token with what is in your database.
>
Jesse Stay
Romeo Olympia
So it looks like that the token being returned to the callback from
oauth/authenticate is now the same request token we sent. Can someone
please confirm this? This is the last message I found on the topic.
If this is the case, how are we supposed to proceed? Should we
exchange the request token for a new access token every time "Sign in
with Twitter" happens?
Thanks,
Romeo
On Apr 17, 9:31 pm, Matt Sanford <m...@twitter.com> wrote:
> Hi all,
>
> This behavior (i.e. which token is returned) is likely to change
> soon. Once again, stay tuned for updates.
>
> — Matt
>
> On Apr 17, 2009, at 01:02 AM, Abraham Williams wrote:
>
> > The oauth_token returned from oauth/authenticate is the key from the
> > users access tokens. as long as you store the access tokens you can
> > match the returned oauth_token with what is in your database.
>
Matt Sanford
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