En esencia, estás usando tu sistema de inicio de sesión para lograr dos objetivos separados:
- Autenticar usuarios regulares
- Permita que los usuarios invitados accedan a páginas autenticadas de otra manera
Como regla general, el uso de una cosa para dos propósitos tiende a causar sus propios problemas a largo plazo, y por lo tanto, SRP sugiere que esto es una mala idea. Ciertamente hay muchas maneras en que esto puede causar problemas:
- Aún necesitará controles de acceso para asegurarse de que los usuarios de esta cuenta de invitado no tengan acceso a otros puntos finales de la API a los que se supone que no deben acceder. Esto, de hecho, probablemente sería mi mayor preocupación: al escribir un nuevo punto final de API sería muy fácil olvidar "Oye, tenemos usuarios invitados que usan este otro inicio de sesión especial" y, por lo tanto, olvidan evitar el acceso a una nueva API para dichos usuarios invitados. Si esa API trata con información confidencial, entonces puede terminar con una violación de datos públicos y críticos.
- Al permitir que muchos usuarios compartan una cuenta, usted hace que los registros de acceso a datos y auditoría sean mucho más difíciles de implementar de manera efectiva.
- Si alguna vez necesita cambiar las credenciales de la cuenta de invitado, no puede hacerlo sin cerrar sesión en todos los usuarios invitados activos.
Hay dos rutas alternativas que podrías tomar:
1. Puntos finales separados que no requieren inicio de sesión
Esto tiene muchas ventajas. Por supuesto, tiene que crear un conjunto separado de puntos finales, pero agregará una capa entre sus usuarios no autorizados y sus sistemas autorizados. Esto hace que sea más difícil para ellos encontrar puntos débiles en la seguridad (ya que están limitados a un subconjunto mucho más pequeño de su sistema) y también dificulta que los desarrolladores cometan errores. Cuando hay una separación clara entre, por ej. "Este código es para usuarios autorizados" y "Este código es para usuarios no autorizados", por lo tanto, es más difícil para alguien olvidar en qué parte están trabajando y, como resultado, cometer un error de seguridad (tenga en cuenta que dije más difícil, no imposible). Esto hará que sea más fácil asegurar adecuadamente sus puntos finales, incluso si no puede cuantificar con precisión el resultado final.
2. Cuentas de invitados separadas para cada usuario con controles de acceso restringido
No hay un montón de antecedentes en tu pregunta, pero en base a lo poco que puedo ver, esto probablemente no tenga sentido para ti. Todavía pensé que nunca está de más mencionar cosas. Otra opción es simplemente crear una cuenta de invitado separada para cada usuario "invitado" de su sistema. Esto funciona mejor si su sistema ya tiene controles de acceso claros en su lugar (de modo que puede bloquear con confianza a esos usuarios en lugares donde no se supone que deben estar) o si se usa junto con un conjunto separado de puntos finales de API (es decir, los usuarios invitados son automáticamente bloqueado de todos los puntos finales excepto estos públicos).
Terminas con un poco más de código para administrar de esta manera (en lugar de tener algunos puntos finales completamente abiertos) pero tiene algunas ventajas:
- Puede realizar un seguimiento más limpio de los usuarios invitados en su sistema, suponiendo que ya está realizando un seguimiento de sus usuarios en función de sus inicios de sesión
- Si tiene un concepto de "convertir" a estos usuarios invitados en usuarios completos de su sistema, ya habrá terminado el proceso cuando llegue el momento de la conversión, y luego podrá realizar un seguimiento del historial de un usuario. desde antes de que incluso "oficialmente" se registraron.
- Dependiendo de cómo un usuario se convierta en una de estas cuentas invitadas, sus puntos finales "públicos" no tienen que estar completamente abiertos. Es decir. Si un usuario hace clic en el botón "Aceptar términos y condiciones" y luego se convierte automáticamente en un usuario invitado, y tiene que ser un usuario invitado para acceder a estas páginas "públicas", entonces habrá eliminado la mayoría de los bots y el raspado automático. sistemas desde sus puntos finales.