Registro interno vs. OpenID vs. Google Friend Connect vs. Facebook Connect vs. (etc)

Question

Estoy tratando de decidir cómo permitir que los usuarios se registren en mi sitio web ... openID, clickpass, facebook connect, google friend conéctese, etc., o los buenos anticuados de la empresa "ingrese un nombre de usuario, correo electrónico, contraseña, etc."

Mirando brevemente How to set-up OpenID parece que hay mucho trabajo para obtener el funcionamiento de openID.

¿Alguien tiene experiencia en la configuración de un sitio para OpenID (u otros)? Además, ¿alguien sabe si estos métodos tienen una mayor tasa de rotación de registro que el registro clásico "interno"? Por ejemplo ... si permite tanto el registro interno como el openID, ¿qué porcentaje de sus usuarios usa OpenID?

Como siempre, gracias por su entrada SO.

Answer 1

Realmente depende del tipo de sitio y quiénes son sus usuarios.

Examinamos la posibilidad de utilizar OpenID para nuestra tienda de comercio electrónico (vendemos prendas de vestir), y la conclusión fue que sería implacable implementarla. No soy el desarrollador de software más inteligente del mundo de ninguna manera, pero si I apenas podía hacerlo, solo para obtener una cuenta para StackOverflow (¿Por qué tengo que ir a un proveedor de terceros? ¿Por qué debería? Confío en ellos? ¿Qué pasa con mi cuenta si se hunden? Como negocio, ¿qué hago si un cliente me pide que restablezca su contraseña?), Entonces no es solo anecdótico decir que nuestros clientes tendrían problemas con eso. Además, para cualquier negocio de comercio electrónico, generalmente no es prudente asumir una dependencia de terceros a menos que se considere cuidadosamente, y especialmente para algo tan crítico como iniciar sesión. Si un importante proveedor de OpenID fuera a fallar, estarías perdiendo ventas. Si implementamos OpenID, definitivamente sería una implementación alternativa, pelirroja y paso a paso en comparación con el mecanismo de inicio de sesión nativo.

Incluso con nuestro registro interno de direcciones de correo electrónico y contraseñas, tuvimos que usar un formulario de inicio de sesión de estilo de Amazon.com porque los usuarios seguían rellenando el formulario "nuevo cliente" incluso cuando ya tenían una cuenta:

Pantalla de inicio de sesión. La pantalla de inicio de sesión de Amazon sigue siendo un modelo a emular, lo que minimiza el problema común de los nuevos clientes que intentan iniciar sesión sin haberse registrado. Amazon presenta dos preguntas en orden lineal: (1) "¿Cuál es su dirección de correo electrónico?" y (2) "¿Tiene una contraseña de Amazon.com?" Para la segunda pregunta, los usuarios pueden seleccionar uno de los dos botones de opción: "No, soy un cliente nuevo" o "Sí, tengo una contraseña". Muchos otros sitios presentan las secciones de usuarios nuevos y establecidos una al lado de la otra, y por lo tanto desvían a los nuevos usuarios a la sección de usuarios establecidos a través de la atracción magnética de los campos de tipo entrada. - Jakob Niesen, useit.com

Cuando los usuarios tienen dificultades para navegar por dos campos y un botón de opción, se puede imaginar la hilaridad que se produce cuando se presentan con múltiples mecanismos de autenticación.

Si está implementando un sitio web orientado a las redes sociales que está diseñado para integrarse con Facebook o con algunos de los consumidores conocedores de Web 2.0, entonces estos mecanismos de autenticación alternativos pueden tener sentido. Hasta que el polvo se asiente en OpenID, sin embargo, no lo agregaría a un sitio comercial: nadie lo había solicitado. Ellos han pedido para PayPal y Google Checkout, que implementamos, pero solo hay una pequeña cantidad de superposición allí.

Mi recomendación general sería tener el mecanismo habitual de nombre de usuario y contraseña que se puede complementar con estos mecanismos de identificación alternativos.Pero tenga en cuenta que cada mecanismo de identificación alternativo corre el riesgo de la confusión del cliente y una mayor atención al cliente.

Solo mis dos centavos; Espero que ayude.

Answer 2

Si necesita mantener información de estado sobre sus usuarios (preferencias y similares), entonces probablemente deba proporcionar su propio mecanismo de usuario/contraseña. Esto no evita que los usuarios aprovechen OpenID y su tipo. La pregunta que debe responder es cuánto tiempo debe dedicar a su proyecto para respaldar más de un método. Como todas las decisiones de diseño, hay un costo y un beneficio para todo. Pésalos a los dos y elige la respuesta que se ajuste a tu presupuesto.

Answer 3

Otra opción posible, en lugar de modificar el código OpenID usted mismo con las bibliotecas, es usar un servicio SaaS como RPX. Puede obtener OpenID, Facebook & myspace de inicio de sesión en un par de horas. Su aplicación solo necesita poder hacer HTTPS y analizar resúmenes JSON o XML.

Answer 4

@Nicolas tiene algunos muy buenos puntos.

Recomiendo comenzar con nombre de usuario/contraseña estándar, y agregar OpenID, etc. como opciones más adelante si suficientes usuarios lo solicitan (al igual que el tutorial de Plaxo).

Siempre es mejor tener un sitio de trabajo ahora, en lugar de un proyecto que se conserve en la marca del 90%. :-)

Answer 5

Estoy planeando hacer algo similar en mi sitio de red social pero un poco diferente de otros sitios. La mayoría de los sitios permiten a los usuarios iniciar sesión con estos servicios, planeo agregar estos servicios a mi formulario de suscripción, luego seleccionan el servicio, openID, facebook connect, myspace ID, luego lo que planeo hacer es obtener toda la información que brindan estos servicios y guárdelos como una variable en mi script php y luego guárdelos en DB; el concepto es permitirles importar información de otros servicios al registrarse para facilitar su suscripción, lo que significa menos campos de perfil que deberán completar más adelante y tales

Answer 6

Mirando brevemente cómo de configurar OpenID parece mucho trabajo para conseguir openID de trabajo.

Realmente no es mucho trabajo. Para un proyecto que aún no está cerca de ser público, descargué Dope OpenID y después de solo unas horas (la mayoría me paso haciendo CSS/HTML que realmente odio) de jugar, tenía una configuración de procedimiento de inicio de sesión que se ve y funciona como la que ves al iniciar sesión en SO.

.. Por ejemplo, si usted permite que tanto el registro en la casa y openID, lo porcentaje de sus usuarios utilizan OpenID?

Ahora, cuando usted puede utilizar Yahoo, AIM y Gmail está registrado como OpenID no hay realmente mucho sentido en la creación de su propia verificación del usuario y tiene que preocuparse de salazón hash correcto y de cosas como si los usuarios no poder ingresar 3 veces/second debería prohibirse por unos minutos, restaurar contraseñas cuando los usuarios se olvidaron de ellas, etc.

Por supuesto, también puede proporcionar un inicio de sesión normal, pero aún así tendría que llevar todas las cosas buenas que OpenID tus hombros. No es tan aterrador pedirle a los usuarios que registren la cuenta de gmail o yahoo que pueden usar, la mayoría de ellos ya tienen una.