No, Sign in with Twitter doesn't have the same flow as Facebook Connect.
 With Facebook Connect, once your sessions are created, they remain for that
user for a given time.  The user doesn't have to go through the entire login
process again each time you request a signature for them.  With Twitter, the
user has to go to an *entirely* different page, log in if they haven't,
click accept or decline, and then come all the way back to your site, *every
I also don't get why you think Facebook Connect is difficult to debug.
 Sounds like more an issue of education than not.  I've had worse issues
with OAuth debugging, to tell you the truth.  All the methods are provided
for you in Facebook Connect to know exactly what's going on - it's actually
very simple compared to the work I've done with OAuth, and the user never
has to leave my site to login.  With OAuth, there's no way of verifying if
your URL was written correctly, or what the issue was when tokens weren't
returned.  With Facebook, all that work is done for you, no coding necessary
on your end until the user is authenticated.  It's incredibly simple.


On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams <> wrote:

> Personally I've found JavaScript based auth systems like Facebook Connect
> and Google Friend Connect to be very difficult to debug and use. I am also a
> lot more comfortable with PHP then JS.
> As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click
> a link on your site, jump to provider to authorize, and return to consumer.
> Abraham
> On Thu, Jul 30, 2009 at 22:12, Jesse Stay <> wrote:
>> I understand the reasoning behind OAuth, and think it's a step in the
>> right direction, but, does Twitter have plans to improve and move to a
>> better Auth system than OAuth?  With Facebook Connect I just have to click
>> once, and if the user is already logged in and approved my app, they never
>> see the Facebook login box again.  Where as with Twitter there are 3 points
>> of potential failure every single time the user logs in.  It's a Ux
>> nightmare, IMO.  While it does solve a problem, I don't think OAuth is the
>> end or ideal solution.  Are there plans to improve this process?
>> Jesse
>> On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams <> wrote:
>>> Well said, Duane.
>>> Thanks,
>>> Doug
>>> On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands <
>>>> wrote:
>>>> First, let me state from the start that I am no fan of OAuth,
>>>> Twitter's implementation of it, or the way that they've behaved with
>>>> regard to it.  Now, with all that being said.
>>>> If your website expects me to hand over my Twitter password, I'm not
>>>> using your web site.  Just yesterday, another scam site (TwitViewer)
>>>> managed to steal thousands of accounts, and convince other people to
>>>> hand over their information because it was posting tweets from the
>>>> stolen accounts.
>>>> OAuth is not perfect, but it provides individual users and Twitter
>>>> with a way to identify bad actors and lock them out of the ecosystem.
>>>> OAuth works.  There are examples out there.  There are developers who
>>>> are willing to help you.
>>>> Implementing OAuth tells your customers that the security of their
>>>> account is important to you, and shutting down Basic Auth trains your
>>>> users to stop giving away their password.  If your product has value,
>>>> and you clearly communicate what that value is, the users will use
>>>> OAuth.
>>>> On Jul 29, 9:10 am, Dewald Pretorius <> wrote:
>>>> > It would not surprise me at all if using OAuth resulted in fewer
>>>> > signups.
>>>> >
>>>> > Potential technical advantages of OAuth aside, every additional click
>>>> > that you add in the conversion process adds an addition leakage point
>>>> > where some users can and will abandon the signup process.
> --
> Abraham Williams | Community Evangelist |
> Hacker | |
> Project |
> This email is: [ ] blogable [x] ask first [ ] private.
> Sent from Madison, Wisconsin, United States

Reply via email to