Creo que todas las respuestas anteriores son incorrectas. @Andy probablemente respondió a tu pregunta, aunque de forma demasiado vaga. El problema es que (a) está asumiendo que sus usuarios son un vector de amenaza (explotar las cookies para obtener acceso no autorizado) (b) que desea usar cookies como parte de su mecanismo de autenticación. A medida que sucede, lo que realmente desea implementar es un tipo de seguridad de confianza cero, un modelo que dice que no se debe confiar en ningún usuario en ningún caso en ningún aspecto (esto es bastante difícil de entender al principio).
Básicamente, la implicación es que puede usar cookies, pero estas deberían ser simplemente cookies de sesión. Shibbeloth y otros diseños similares para instituciones académicas en el Reino Unido, utilizan una combinación de cookies de sesión, autenticación de terceros (en la institución) y autenticación de sesiones basada en la base de datos (en comparación con las otras dos). De hecho, por lo general también verifica los derechos de los usuarios en la institución (es decir, si está estudiando ciencias de la computación, no necesita la biblioteca médica, etc.).
Entonces, usar una cookie persistente es su problema, este es un no-no definitivo. Parece que ya comprendes el riesgo de usar una cookie persistente, que es que puede ser robada (generalmente en texto plano). Por lo tanto, utilice cookies de sesión no persistentes en el peor de los casos.
Lo que debería hacer, en mi opinión, si usara este método de autenticación es revocar las cookies con regularidad y requerir que el usuario vuelva a iniciar sesión. Como he explicado, Shibbeloth tiene múltiples factores de diseño ya que compara tus credenciales con las de tu universidad. Mejores diseños no solo compararían la información del usuario, sino que requerirían más de una credencial (es decir, un mensaje de texto, correo electrónico o una respuesta secreta como en la banca en línea).
De manera realista, la mayoría de las aplicaciones que están basadas en la web pueden beneficiarse enormemente de ser apátridas (dependiendo de la aplicación y los requisitos del usuario / sistema). Por lo tanto, puede eliminar las cookies de la sesión casi por completo al usarlas hasta que la ventana del navegador se cierre / el tiempo transcurrido o mediante el uso de un almacén de usuarios del lado del cliente cifrado (mejor solución).
Entre otras mitigaciones que otros usuarios han dicho, como los navegadores de huellas digitales y los patrones de uso de monitoreo, hay muchas estrategias que podría emplear. También puede usar listas blancas de IP, anti-DDoS, reinversión de credenciales regulares, etc. Son complementarias, pero no son una solución por sí mismas.
Lo que nunca debe hacer es eliminar la prioridad de las fallas de seguridad y software para mejorar la experiencia del usuario (por cierto, son lo mismo). Si hace esto, un día podría ser responsable de una catástrofe de protección de datos (y posiblemente ir a la cárcel y / o perder mucho dinero).
Para implementar completamente lo que está buscando, use una aplicación web (probablemente basada en javascript) que no necesita ser instalada. Esa aplicación debe programarse para implementar completamente su API y hacer todo el trabajo pesado para el usuario. Lo ideal es que lleve a cabo el control de acceso basado en roles (RBAC) a través de esa API (identifique los diferentes grupos de usuarios que ha mencionado). Obviamente, el RBAC debe implementarse en el lado del servidor. No hay ninguna razón por la que su API no pueda proporcionar o enlazar directamente a este y almacenar tokens emitidos directamente, oa través de otro canal, como un tokenw basado en mensajes de texto.
Espero que esto te ayude a pensar en relación con tu diseño.