He estado leyendo sobre esto durante meses y parece que todo podría converger en lo que estoy resumiendo a continuación. Estoy tratando de llegar a lo más ideal:
- OAuth2
- OpenID Connect
- SPA / Cliente móvil
- JWT
La solución que tiene calidad de seguridad a nivel bancario como el componente anterior se refiere. Así que esto es lo que parece tener sentido.
- Use la Otorgamiento del Código de Autorización sin usar las sesiones y cookies del lado del servidor ya que este flujo de OAuth es más seguro que el flujo implícito.
- No cree sesiones o cookies del lado del servidor (además de quizás recordar las cookies para identificar si el cliente ha sido autenticado anteriormente). Esto es mejor para la escala y la simplicidad general.
- Devuelva un token de conexión JWT / OpenID al cliente para que el cliente pueda usarlo para realizar solicitudes de API y para tomar decisiones de autorización dentro del cliente. (Creo que esto es lo que el OAuth2 código de autorización de concesión / flujo implícito es?). Almacene el token de conexión JWT / OpenID en el almacenamiento de sesión de los clientes.
- Tener tokens JWT de corta duración y también ofrecer token de actualización hasta que el usuario cierre la sesión. El cliente recibiría automáticamente tokens de actualización a menos que se agote el tiempo de espera / la sesión del lado del cliente caduque o el usuario cierre la sesión.
- Al cerrar sesión (o tiempo de espera), elimine el token del almacenamiento de la sesión del navegador.
¿Alguno de estos locos / suena razonable? Omite tokens de invalidación, pero parece correcto hacer esto si las tokens tienen tiempos de vida muy cortos y el cliente puede obtener tokens de actualización. Me gustaría implementar esto usando Spring-Boot / Spring Security y Angular 4/5 y me pregunto si me he perdido algo obvio o quizás hay un enfoque aún más simple que no sacrifica / reduce la seguridad?
¿También cree que esto pasaría la verificación de los estándares de seguridad de nivel "Banca"?