¿Cómo gestionan las empresas la autenticación en sus aplicaciones web multiusuario?
Esencialmente, tengo una sola instancia de base de datos PostgreSQL con muchas tablas. Cada tabla tiene una columna workspace_id que usaré para otorgar/denegar acceso. Puede pensar en un espacio de trabajo como un cliente y un solo usuario puede asociarse con varios espacios de trabajo.
Mi pensamiento inicial fue:
jwt que contiene los detalles del usuario y la identificación del espacio de trabajo.Estoy a la mitad de la implementación de lo que describí anteriormente, pero no estoy seguro de si ese es el mejor enfoque. ¿Qué piensas?
No estoy seguro de llamar a esto multiusuario; en realidad, es solo un caso de diferentes usuarios con diferentes claims :
Cuando su interfaz de usuario llama a las API, el back-end debe recibir un token de acceso JWT con cualquiera de estas cargas útiles. Se prefiere el segundo de estos, pero no todos los sistemas lo admiten:
LA OPCIÓN MÁS SENCILLA
Esto podría ser solo para buscar las ID del espacio de trabajo del usuario cada vez que se recibe una solicitud de API, según la ID de usuario en el token de acceso JWT, como en el comentario de Joe anterior.
PRINCIPAL DE RECLAMACIONES
Si los Id. de espacio de trabajo se utilizan con frecuencia para la autorización en muchas solicitudes de API, entonces una mejor opción es diseñar un objeto Claims Principal que contenga datos que la API suele utilizar para la autorización y que contenga los Id. importantes. Podría verse así para un usuario en particular:
{ sub: "wdvohjkerwt8", userID: 234, workspaceIDs: [2, 7, 19] }Este objeto generalmente debe estar compuesto por datos de identidad (almacenados por el servidor de autorización) y también datos específicos del dominio. El ID de usuario anterior puede ser una clave de base de datos, mientras que la notificación del asunto suele ser un valor generado.
Cuando se recibe una solicitud de API, puede leer todos los reclamos del token de acceso de JWT o combinar datos específicos del dominio con los datos de JWT.
Luego, Claims Principal se inyecta donde sea necesario, de modo que su lógica de autorización de API se pueda codificar de una manera simple. En su caso, esto implicará filtrar espacios de trabajo cuando trabaje con colecciones, o denegar el acceso si el usuario intenta acceder específicamente a un espacio de trabajo al que no tiene derecho.
Aquí hay un ejemplo de código mío de Node.js que hace esto, usando un region array claim :