...
El frontend llamará al servicio que requiera del backend pasándole el token OAuth, el identificador de sesión y los parámetros que requiera propios de dicha llamada. Una vez recibida esa petición en el endpoint y validado el token, se extraerá el campo jti a partir del cual se recuperará identificador de usuario que, junto con el identificador de sesión, se usará para recuperar la sesión del usuario en curso. En la lógica del endpoint se debe contemplar de manera explicita la recuperación de la sesión.
...
Tras realizar todas las acciones pertinentes, el endpoint deberá actualizar el estado de la sesión y devolver el flujo al frontendofrontend.
Cierre de sesión
La sesión podrá cerrarse de dos maneras: de manera explícita desde el frontend, de manera implícita por que caduque. Como POSE es un portal distribuido compuesto por varias aplicaciones, podemos delegar el cierre de sesión al propio portal el cual eliminarña el ID de sesión para el usuario en curso, o bien tener un cerrar sesión explícito en el último paso de nuestras aplicaciones de manera que, para nuestra aplicación, se borre de la tabla la sesión en curso porque hemos completado ya el proceso (por ejemplo en el último paso de un wizard).
Es importante cerrar la sesión Al estar la sesión asociada al token OAuth es importante cerrarla cuando consideremos que el flujo que ha seguido el usuario por la aplicación ha terminado ya que de lo contrario al volver a ejecutar el servicio se cargará la última sesión guardada.
El cierre de sesión lo gestionaremos mediante eventos para que no interfiera con la respuesta al frontend. El servicio lanzará un evento indicando qué sesión hay que cerrar y otro método (que estará escuchando ese tipo de eventos) se encargará de borrar el registro de base de datos.
Recuperar sesiones en pasos intermedios
Una implementación que podemos hacer en nuestros servicios que inician un proceso es comprobar si existe una sesión en base de datos y notificar al usuario que ya tiene una sesión completa hasta el paso X, preguntando si quiere continuarla o empezar una nueva. Esta lógica puede ser útil para tener en cuenta los casos en que se produzca un fallo sin que se pudiera cerrar la sesión, por ejemplo que el usuario se quede sin conexión a mitad de un proceso, reinicie el equipo y vuelva a probar.
...