Usuario autenticado en movimiento para un servicio diferente

Esto es muy parecido a un servicio de inicio de sesión único, excepto que generalmente usted no controla todos los servicios (en su lugar, uno de ellos está controlado por el proveedor de SSO, como Facebook o Google). Puede consultar OAuth2 para obtener algunas ideas de cómo se implementa con mayor frecuencia el SSO, pero honestamente es una exageración para un escenario en el que usted controla ambos servicios.

Suponiendo por el momento que usted controla ambos servicios y que las llamadas entre ellos son lo suficientemente baratas, una solución simple es que uno de ellos sea la fuente de la verdad en la identidad, por lo que service2 simplemente verifica service1 para confirmar quién es el usuario y qué pueden hacer (cuáles son sus datos secretos, cuántos créditos tienen, etc.), sin almacenar nada de esa información en sí. El problema entonces es vincular la sesión del usuario a través de ambos servicios.

Puede utilizar el enfoque de URL:

1. service1 genera un token aleatorio seguro de un solo uso y lo pasa a service2 en la URL
2. service2 envía ese token a service1 a través de un canal directo
3. service1 responde con un identificador de sesión para la sesión del usuario y cualquier otro servicio de datos adicional definitivamente querrá
4. service2 establece el identificador de sesión de service1 como su propio identificador de sesión en el cliente (probablemente en una cookie segura) y, opcionalmente, almacena los datos requeridos en su propio estado de sesión para esa sesión

Alternativamente, puede usar CORS (Intercambio de recursos de origen cruzado), que es una forma para que un navegador web rompa la política del mismo origen de forma controlada entre sitios que confían entre sí (y posiblemente estén controlados por el mismo). entidad). CORS le permite realizar llamadas XMLHttpRequest o Fetch a través de orígenes y ver las respuestas. Un ejemplo podría verse así:

1. service2 recibe una solicitud de un nuevo usuario que no tiene una sesión, o un usuario cuya sesión ha caducado
2. service2 responde con una página que contiene un script que realiza una solicitud CORS, con autenticación, a service1
3. Suponiendo que el usuario ha iniciado sesión en service1, service1 acepta la solicitud CORS y responde con un token aleatorio de forma segura y de uso único
4. La secuencia de comandos del lado del cliente envía este token al servicio 2
5. service2 envía este token a service1 a través de un canal de respaldo directo
6. service1 verifica el token y envía un identificador de sesión a service2, etc.

Este esquema es el mismo que pasar el token en la URL, con dos excepciones:

• El token nunca se envía en la URL y, por lo tanto, es mucho menos probable que termine en algún lugar donde no debería estar el registro del servidor o el historial del navegador.
• El usuario puede ir directamente a una URL de service2 sin hacer clic a través de un enlace especial desde service1, siempre que tengan una sesión activa en service1.

Tenga en cuenta que el token de sesión en sí nunca se envía en un cuerpo de respuesta (que el cliente ve). Podría simplificar este esquema si lo hiciera; entonces el script del cliente establecería el ID de sesión en una cookie para service2, eliminando un viaje de ida y vuelta cliente-servicio2 y un viaje de ida y vuelta service2-service1 - pero un atacante con un XSS podría robar el token de sesión ( en lugar de "simplemente" tener control remoto completo sobre la sesión comprometida mientras el usuario tenga la página cargada).