Para mi trabajo, tenemos un buen servicio web RESTful que hemos desarrollado y que utilizamos para manejar un par de sitios web que tenemos. Básicamente, el servicio web le permite crear y trabajar con tickets de soporte, y el sitio web es responsable del front-end. Cualquier solicitud de servicio web utiliza un encabezado de autenticación que utilizamos para validar al usuario y su contraseña para cada llamada.
Este año buscamos expandir nuestras opciones de inicio de sesión para que los usuarios en el sitio web puedan iniciar sesión a través de Google, Twitter y Facebook (posiblemente otros). Sin embargo, tengo muchos problemas para descubrir cómo diseñar esto para que el servicio web pueda usar los proveedores de autenticación de terceros para garantizar que los usuarios sean quienes dicen ser. ¿Existe alguna práctica recomendada sobre cómo hacer esto?
Actualmente estamos pensando en que el sitio web maneje la autenticación de los propios usuarios y luego use una nueva llamada setSessionId que registre su sesión actual con el back-end del servicio web. Cada solicitud adicional al servicio web pasará ese ID de sesión y lo validará. Esto parece estar bien, pero tengo la sensación en el fondo de mi cabeza de que no estoy pensando en esto y toda mi búsqueda en el foro y la lectura de las especificaciones de Openid y Oauth me confunde aún más. ¿Algún consejo sobre cómo abordar esto?
fuente
Respuestas:
Parece que hay dos objetivos:
Al autorizar a las personas a usar recursos en su sitio, OAuth2 es un mecanismo preferido debido a la popularidad y disponibilidad de las bibliotecas de los clientes.
1. Fácil para que los usuarios finales se autentiquen con sus cuentas sociales existentes
El usuario final visita un sitio que usa su API y elige iniciar sesión. Se envían a su página de inicio de sesión de OAuth. Su página de inicio de sesión muestra un mensaje de nombre de usuario y contraseña normal para las cuentas administradas en su sitio y un conjunto de botones de autenticación social donde pueden hacer clic para iniciar sesión a través de un sitio como Facebook. Cuando el usuario elige Facebook, lo redirige a Facebook para aprobar la elección (iniciando el flujo de autenticación de Facebook). Cuando el usuario final completa el inicio de sesión en Facebook, se lo redirige a su sitio.
Cuando el usuario es redirigido a su sitio desde Facebook, guarda la información de ese usuario en un registro de usuario en su base de datos y luego genera una nueva sesión para ese usuario. Inmediatamente redirige al usuario final a su sitio descendente original con oauth access_token, completando el flujo original de oauth.
2. Fácil para los desarrolladores que utilizan su servicio web
Si usted es el proveedor de la autorización, debe crear una interfaz simple para que los desarrolladores dependan de la cual no cambia cada vez que agrega un nuevo proveedor de autenticación ascendente que no implementa perfectamente oauth. Es por eso que creo que debe implementar un sitio de proveedor OAuth2 y ese sitio debe ser un consumidor de los sitios de autenticación social.
Para el desarrollador que usa su API de descanso agradable, no estarán al tanto de la interacción de Facebook a menos que elija darles una pista a través de la publicación de captura de sesión (por ejemplo).
TL; DR
Haga que los consumidores de sus API como usted implementen OAuth2 y oculte las complejidades de la autenticación social. Puede, durante su flujo de oauth para sus sitios aguas abajo, activar un flujo de oauth adicional con facebook.
Imagen porque imagen == palabras * 1000:
¿Podemos llamar a esto oauth2-piggy-back?
Paso a paso
stateen Facebook oauth para saber de dónde vino el usuariofuente
Cómo hacerlo extensible
Primero debe notar que todas estas API usan el mismo mecanismo para iniciar sesión. Todas usan OAuth para su autenticación. Debe aprovechar esto comenzando con una biblioteca general de OAuth. No use sus propias bibliotecas para la autenticación, estas serán inutilizables para otros proveedores. Si te acostumbras a OAuth2, es bastante fácil agregar más proveedores.
Desafortunadamente, necesita dos de ellos, porque Twitter aún no ha subido al tren de OAuth2.
OAuth necesita que cree una interfaz para la parte que autentica. Los tokens se intercambiarán de servidor a servidor. Cree un punto de entrada, que pueda manejar toda la comunicación.
El token debe almacenarse en una tabla separada de su cuenta, esto se debe a que pueden ser múltiples tokens y múltiples perfiles vinculados. Algunos servicios le dan dos tokens, uno de ellos es un token de actualización.
Ahora diseña una interfaz, que encapsula la otra funcionalidad que necesita. Yo personalmente configuraría un servicio REST separado para esto. De esta manera, puede extender fácilmente la autenticación a otros lugares.
Algunos servicios utilizan JSON para comunicarse, otros utilizan XML, etc. Para el usuario frontal, debe unificarlos a todos. Este es un proceso bastante doloroso, pero es posible derivar algunos puntos comunes aquí.
Otro problema aquí es que no todos los servicios ofrecen la misma funcionalidad. Esto puede significar que sus servicios no pueden proporcionar la API completa como usted especificó. Debe tener una estrategia aquí, que permita que la aplicación baje de categoría con gracia.
Todo esto asegurará que pueda agregar fácilmente nuevos proveedores de terceros.
Problemas de token
Los tokens están limitados en el tiempo, por lo que necesita un par de trabajos cron, que pueden verificar si el token todavía es utilizable, de lo contrario, debe eliminarlo. También puede actualizar un token mediante este mecanismo.
A veces sucede que un usuario retrae el token. Prepárate para esto.
Almacenamiento de datos
Si tiene este diseño, debe pensar en los datos que necesita. Esto se debe en parte a su interfaz recién creada. Diseñe algunas tablas para esto y observe si los datos son realmente recuperables. Algunos servicios no le permiten obtener muchos datos. También debe tener en cuenta que cuantos más datos necesite, más pesados serán los mensajes de privacidad. Por lo tanto, sea modesto en sus necesidades, de lo contrario los usuarios no lo usarán.
Para una verificación adicional, puede almacenar los perfiles en una tabla separada pero vinculada a sus usuarios. Esto le proporcionará mucha más información sobre alguien.
Consulte también sus leyes locales, para algunos datos necesita precauciones adicionales.
Lo último No cometa la culpa de no crear una cuenta en sus propios servicios. Si se excluye al usuario de Facebook, no podrá iniciar sesión en su servicio. Esta es una situación que no quieres crear. Esto a menudo se pasa por alto.
fuente
Definitivamente, elegiría la solución que parece que ya ha descubierto: implementar la autenticación de terceros en su sitio web orientado al cliente y luego asociar esos tokens de autenticación de terceros con las cuentas de usuario de su sitio web, y finalmente activar su llamada setSessionID en iniciar sesión.
Dependiendo de la arquitectura de su sitio web, puede ser muy útil usar una biblioteca como EveryAuth o Passport .
fuente
Mis dos centavos: nunca antes había hecho algo así ni sé cómo funcionan los mecanismos de inicio de sesión de FB, Twitter o Google, pero surgieron algunos problemas en mi cabeza tan pronto como leí tu pregunta:
Podemos lidiar con estos dos problemas eligiendo asociar las cuentas externas con una cuenta interna, no solo una ID de sesión. Entonces, un inicio de sesión externo podría ser solo una puerta de entrada a la creación de una cuenta interna. Si me autentico con más de un método de inicio de sesión, podría decirme que ya he iniciado sesión. Si un proveedor de autenticación externo cambia algo en lo que confiamos, podríamos pedirle al usuario que proporcione el nombre y la contraseña de su cuenta interna y cree un nueva asociación para futuros inicios de sesión.
No estoy seguro de haber abordado los problemas que tenía en mente, pero realmente no mencionó ninguna preocupación concreta. Espero que mi respuesta haya sido útil, de cualquier manera.
fuente