Estoy construyendo una aplicación web con una arquitectura básica de cliente-servidor. El frontend se ejecuta con react (nextjs) y el backend está sobre rieles. Sin embargo, las preguntas serán más sobre el flujo de autenticación/autorización + manejo de sesión en la interfaz.
Estoy usando un proveedor de Oauth para manejar la autenticación , pero no necesito ninguna autorización de su parte, ya que no necesito los recursos del proveedor de Oauth (por ejemplo, unidad, calendario, etc.)
Para la autorización, como quiero acceder a los recursos de mi API, es la propia API la que maneja la autorización en cualquier solicitud realizada por el cliente (frontend) a la API de Rails.
En este momento, para la autenticación inicial, este es el flujo que estoy usando, tomado de https://blog.prototypr.io/how-to-build-google-login-into-a-react-app-and-node-express -api-821d049ee670 :
Detalles de implementación importantes para las siguientes preguntas:
Estoy usando JWT como token de acceso (aquellos generados por mi API) y simplemente los firmo usando una clave secreta que solo está disponible en mi API para que el token de acceso no se pueda leer desde el punto de vista frontal.
En la interfaz, es una aplicación de reacción y utilicé el siguiente paquete para manejar el flujo de OAuth google-react-login
Información recibida, qué usar de Google (proveedor de OAuth) 1- Recibo (entre otras cosas) un IdToken y un token de acceso de Google. También aparentemente se supone que debo recibir un token de actualización (que no vi). Para mi caso de uso, todo lo que necesito es el idToken de Google, ¿verdad?
¿Revocación de un token de actualización (cierre de sesión), flujo para volver a iniciar sesión?
2- Según tengo entendido, los tokens de acceso deben ser de corta duración por razones de seguridad. Por lo tanto, necesito devolver un token de actualización a mi aplicación cliente para poder generar nuevos tokens de acceso con frecuencia. Sin embargo, una vez que un token de actualización llega a su tiempo de caducidad, ¿debo cerrar la sesión del usuario y pedirle que vuelva a iniciar sesión a través de Google y básicamente rehacer los pasos 1 a 5 (consulte la Figura 1)?
Cómo mantener la sesión a través del token de acceso
3- Desde la perspectiva de la interfaz, ¿puedo suponer que el simple hecho de tener un token de actualización significa que el usuario ha iniciado sesión? Una vez que el servidor revoque el token de acceso y el token de actualización, eso significa que el usuario ha cerrado la sesión y necesito mostrar una vista de la aplicación web para un usuario no autenticado. Eso significa que después de cada recarga de página, debo verificar la presencia de un token de acceso y actualización.
Gracias
Creo que podría mejorar su seguridad y reducir la complejidad con una cosa: reemplazar la emisión de sus propios tokens JWT por un servidor OAuth2 personalizado. Este servidor OAuth2 podría usar Google como proveedor de autenticación. De esta manera, no sabría sobre Google y solo usaría su propio servidor OAuth2.
Luego, puede decidir cómo usarlo, si la interfaz será el cliente OAuth2 o el backend.
Si elige la interfaz, utilizará el flujo de código de autenticación con PKCE (como un cliente público). El frontend utilizará un access_token para autorizar sus solicitudes al backend. De esta manera, la interfaz manejará una sesión usando iframes ocultos. Consulte el RFC de administración de sesiones de OpenID Connect .
Si elige el backend, utilizará el flujo de código de autenticación (con un secreto de cliente). De esta manera, su backend puede mantener la sesión usando una cookie (con opciones seguras, solo HTTP, de SameSite).
Puede leer el RFC de OAuth 2.0 para aplicaciones basadas en navegador para conocer las prácticas recomendadas actuales.