¿Por qué es una mala idea usar ClientLogin para aplicaciones web en la API de Google?

Question

Acabo de recoger la API de Google hoy para permitir que algunos usuarios de nuestro sitio carguen videos a nuestra propia cuenta de YouTube de la organización. No deseo que nuestros usuarios sepan nuestro nombre de usuario y contraseña, sino más bien darles la opción si desean subir videos a youtube o no. Si eligen hacerlo, marcan una casilla de verificación y presionan el botón de enviar.

Veo una y otra vez en la guía de desarrolladores que ClientLogin, que a mí me parece la mejor opción para implementar lo que quiero hacer, no es una buena idea para la autenticación de usuario en aplicaciones web. ¡El "AuthSub para aplicaciones web" no parece ser el mejor mecanismo para lo que quiero implementar!

¿Alguna idea sobre qué hacer?

Gracias

Answer 1

Después de jugar con la API de Google y otros proveedores de servicios de video de la API, he aprendido mucho sobre la autenticación. oAuth y AuthSub son dos métodos que usa Google para autenticar aplicaciones web de terceros en una cuenta de usuario.

El proceso puede parecer complicado al principio, pero una vez que lo entiendes, no es tan malo. La siguiente imagen muestra el proceso AuthSub.

1. Cuando la aplicación web necesita para acceder al servicio de Google de un usuario, se hace una llamada al servicio de AuthSub de autorización de mandatario de Google.
2. El servicio de autorización responde presentando una página de solicitud de acceso. Esta página administrada por Google solicita al usuario que otorgue/niegue el acceso a su servicio de Google. En primer lugar, se le puede pedir al usuario que inicie sesión en su cuenta.
3. El usuario decide si otorgar o denegar el acceso a la aplicación web. Si el usuario niega el acceso, se los dirige a una página de Google en lugar de volver a la aplicación web.
4. Si el usuario concede acceso, el servicio de Autorización redirige al usuario a la aplicación web. La redirección contiene un token de autorización válido para un solo uso; se puede cambiar por un token de larga vida.
5. La aplicación web contacta al servicio de Google con una solicitud, utilizando el token de autorización para actuar como agente del usuario.
6. Si el servicio de Google reconoce el token, proporciona los datos solicitados.

http://code.google.com/apis/accounts/docs/AuthSub.html#AuthProcess

Cuando le solicitan que se autenticados y el usuario inicia sesión en su/su cuenta de Google, antes de que él/ella otorga su permiso a la aplicación para hacer cosas en su cuenta, y si su dominio tiene Si no se ha registrado en Google, el usuario recibirá una caja roja desagradable diciéndole que tenga cuidado porque la aplicación a la que están a punto de dar acceso no está registrada con ellos.

Las ventajas sobre estos métodos durante el antiguo nombre de usuario y la contraseña son la escuela (en mi opinión) lo siguiente:

1. seguridad mejorada para el usuario: El usuario no tendrá que darle su nombre de usuario y contraseña, tienen que iniciar sesión en google y obtendrás un token de acceso que usarás para realizar más llamadas a la API. El usuario puede revocar el acceso a su aplicación desde dentro de google si lo desea.
2. El proceso puede dar al usuario la garantía de que su aplicación es "Legit". Si un usuario tiene que ir a través de google para iniciar sesión y permitir su aplicación, puede verse bien si su dominio ha sido registrado con google.
3. El token se puede promocionar a un token de sesión: Esto significa que no tiene que pedirle al usuario que inicie sesión cada vez que necesite solicitar acceso a la cuenta de usuario de google, solo use el token de sesión (que debe asegurar guardar en alguna parte) y listo.
4. Una vez que comprenda el proceso, es bastante sencillo autenticar usuarios.
5. (no verificado) Si el usuario cambia su contraseña, no tiene que actualizar el token de seguridad.
6. Por último, si usa oAuth puede crear una interfaz que le permita autenticar fácilmente a los usuarios cuando se conecte a otros servicios web, como Vimeo.

Con todo esto dicho, supongo que puede averiguar por qué sería una mala idea usar el nombre de usuario y las contraseñas (que es lo que hace el ClientLogin) para conectarse a una cuenta de usuario. Otros métodos de autenticación le permiten hacer lo mismo (solicitar acceso) y agregar un montón de ventajas.

El código sobre cómo autenticar a los usuarios que usan AuthSub se puede encontrar aquí, es más o menos plug n play. solo asegúrese de guardar $ _SESSION ['sessionToken'] en una ubicación más permanente, como un DB.

http://code.google.com/apis/youtube/2.0/developers_guide_php.html#AuthSub_for_Web_Applications

Answer 2

que he tenido el mismo problema, y ​​terminé usando ClientLogin. Si no desea que sus usuarios vean una parte del proceso de inicio de sesión, lo hará.

No sé si hay una forma mejor de hacerlo con AuthSub u otros métodos de autenticación.

Answer 3

ClientLogin no es el mecanismo preferido aquí porque su aplicación se ve obligado a gestionar las credenciales de inicio de sesión para el usuario. Si la identidad del usuario necesita establecerse por más tiempo que una sesión, se verá forzado a almacenar las credenciales y esto no es ideal: el compromiso de su servidor llevaría al compromiso de los usuarios de Google. Por lo tanto, ClientLogin no es el enfoque correcto para su aplicación.

¿Has mirado Google OAuth? Soluciona el problema de manejo de contraseñas de forma muy elegante y es un estándar establecido.