Oauth · APIs

Is requiring two forms of Oauth a bad idea?

Aaron Ellsworth

June 24th, 2013

I'd really appreciate your feedback here.  I'm building a private video based platform in which users would gain access to exclusive content curated based on what they consume, like, etc. on social networks.  I'd like to require a sign-in using google's Oauth APIs and then as a final step in the registration process, to require them to choose another social network (Twitter or Facebook), granting access to their social graphs on that network as well.  Would dual registration be enough to dissuade you from signing up, even if the reason is to provide exclusive content (high production quality) catered to you?  Why or why not?

Ross Stovall Technical Lead - Asia Development at PLAYSTUDIOS

June 24th, 2013

You might want to consider using the method we use in social gaming. Auth with the least amount of friction in the beginning and later ask for extended permissions when it's relevant to something they're doing. For example maybe let them auth in and get a taste of your service and then prompt them to auth with an additional social network to receive highly quality content. I would AB test where in the auth flow converts the highest as well. 

Eric Lange VP Product Management

June 24th, 2013

Requiring two forms?  Terrible idea; I would bail immediately.  Making it optional in order to get more features?  Fine so long as the relationship between giving more info and what you get in return is clear and obvious.  And I mean obvious as in "By giving your twitter OAUTH, you get xyz from your twitter followers", not "give us your twitter id and we will arbitrarily enable x more features that have nothing to do with twitter".

Michael Brill Technology startup exec focused on AI-driven products

June 24th, 2013

Maybe I'm missing something, but I'm not sure what you mean by "Google's OAuth APIs." I'm assuming you're talking about implementing an OAuth provider with that vs. just authenticating users against their Google account. But that doesn't seem to fit with your user model.  Could you elaborate on what the Google bit is?

Michael Barnathan

June 24th, 2013

This isn't a particularly secure way of doing two-factor authentication, if that's what you're driving at. The idea behind two-factor is to combine something that the user knows with something that the user has.

I don't think this is a dealbreaker for most users, but there will be some - you should really think about streamlining the registration process as much as possible. The shorter and easier it is, the less loss you'll take in your "funnel".

James Bond CTO at SupplyBetter

June 24th, 2013

I don't understand your reason for requiring two separate sign-ins. As previous poster wrote, it doesn't add anything in terms of authentication; and my expectation is yes, this will dissuade a lot of people from signing up.

If there's some way in which doing this that adds value to the user experience, I'd suggest making that benefit very clear to users; and even then, making it optional.

Aaron Ellsworth

June 24th, 2013

My understanding is that Google has different APIs to access different types of user information.  In order to access this information I would need an OAuth provider.  Please correct me if I'm wrong; I'm not a programmer.  Yes, this isn't an exercise to simply authenticate a user, but to collect information around a user's social graph from two different sources in order to provide a viewer experience more closely in-tune with their interests.  If I need to be educated as to why this doesn't make sense or why this won't work, please let me know.  I'm here to learn.  Thanks again for the comments.

James Bond CTO at SupplyBetter

June 24th, 2013

In general, OAuth is doing two things. First, it's a way of leveraging the authentication mechanism of some other site (e.g. Google, Twitter, Facebook) for your site -- in effect, you're saying that if they have an account they can log into on the other site(s), you're willing to rely on that for their authentication to your site (that is, they don't need to register & set up a separate name/password on your site). When you use this authentication mechanism, the user is literally redirected to the other site to enter their credentials (you never see those; just the fact that they authenticated successfully); AND as part of this process, they need to explicitly agree to that site reveal certain information to your application. At minimum, the fact that they have an account. 

That leads to the second part. Depending on the provider, they may reveal nothing more. Or, they may be given the option to authorize your application to access additional information on their behalf from that site -- for example (as you mention), their social graph. As part of your OAuth request, you can indicate what such additional information you're requesting access to; but this will (or should) always be made explicit to the user, and they always have the option to decline (or to revoke this access later).

What I'm getting from your last response is that there's information about your users you want to access via Google APIs, as well as Facebook, Twitter, etc.  My recommendation, as several others have suggested, is that you determine what is the *minimum* necessary for users to use your site at all, and only require that for initial sign-up; and then give users the ability to gain additional capabilities (by way of giving auth via OAuth to other sites/services), as on option.

Michael Brill Technology startup exec focused on AI-driven products

June 24th, 2013

Yeah, so you do not need to implement an OAuth provider... just a consumer. It is quite normal for an app/site to connect to two or more services... I'm sure you use plenty of those yourself. You probably noticed that each one you connected to required you to enter your user id/pwd into a popup window. That will be your user experience as well.

So as everyone said, you want to minimize the number of things a user has to do in order to use your app. I'm guessing that Google is just one of several sources for you but is not a requirement. So if you just give the user a list of services they can authenticate with, let them choose just one and then make it easy to connect to additional services later.

However if you require that they connect to at least 2 services for you to do anything, it's still probably better to get the user to connect with one first, move them along the workflow so they feel they've got some skin in the game before enticing them to enter the second service.

Matthew Berk Founder, CEO/CTO at Lucky Oyster, Inc.

June 27th, 2013

We're having a devil of a time just asking people to use the Facebook API to authenticate, and we go very out of our way to say that it's for authentication only. There's a fear--at least among users we've interviewed--that authenticating through a social network puts your content, contacts, and persona there at risk in some fashion. Whether it's true or not doesn't matter. The fear skews more towards older users (35+), we find.

My advice is to use the least intrusive mechanism up front, and to progressive ask for more, once you've shown value.

Jeff Lehmer Cofounder in charge of Software Development at Vivos Software

June 30th, 2013

I agree. You should only require one "social" login for authentication ever.  If your goal is to get them to include other social logins so they connect more sources to your site then _encourage_ them to add other social logins later.  But you might want to word the extra logins as "connections" or "enhancements" rather than as "logins" to make it more palatable and less intrusive.