Almacenamiento de token de autenticación después de la autenticación de la base de datos

2

He trabajado en una aplicación de back-end RESTful de Spring 4 MVC. Nos autenticamos en un servidor OpenAM, y un token largo se almacena en una cookie en el front-end. El front-end saca el token de la cookie y lo pasa como encabezado en cada llamada de Ajax al back-end. Por lo tanto, si llamamos al backend RESTful en una llamada Ajax (POST, PUT, GET), el token se envía como un encabezado llamado "openam_token".

Hemos implementado Spring Web-Security basado en el ejemplo de SiteHeader. Aparece un token como encabezado y tenemos un PreAuthorizationFilter que implementamos llamado "CustomUserDetailsService". Este código toma el encabezado y obtiene el token, pasamos ese token a OpenAM para preguntarles si esto es válido, y si es así, nos devuelve el nombre de usuario de ese usuario. Desde ese nombre de usuario único, podemos buscar al usuario en la base de datos y obtener los detalles del usuario y sus roles.

Supongo que si he creado un inicio de sesión desde Google+, LinkedIn o Facebook, el proceso es el mismo. Pasamos a su página de inicio de sesión, el usuario se autentica y luego un token regresa. El token se almacena en una cookie en el lado del cliente. Cada llamada de Ajax desde ese front-end al backend devuelve el token en el encabezado, y luego en CustomUserDetailsService ... llamamos a LinkedIn, Google+ o Facebook, y vemos si el usuario es correcto. Pero esto se debe a mi presunción de cómo funcionan, pero podría estar completamente equivocado.

Por lo tanto, en la aplicación Spring RESTful en la que estoy trabajando. Los nombres de usuario y las contraseñas se almacenan en la base de datos junto con el salt. He investigado mucho sobre cómo almacenar la sal con el nombre de usuario, una sal única que se genera cuando se crea el usuario o cuando se cambia su contraseña.

Entonces, siempre que un usuario proporcione un nombre de usuario y contraseña, y el usuario se haya autenticado ... Quiero generar un token para este usuario, y me pregunto cuáles son las prácticas comunes para generar un token.

Segundo, ¿dónde está el mejor lugar para almacenar ese token? Si el token regresa, supongo que también puedo guardar eso en una cookie en el lado del cliente, al igual que lo hacemos cuando nos autentificamos contra OpenAM. Ahora, ¿cuál sería la mejor manera de almacenar esos tokens temporales en el backend? Podría persistir el token en la tabla de usuarios junto con el usuario. Podría guardar esas fichas en otra mesa. La idea es ... los tokens, almacenados en las cookies, deben coincidir en el backend para ese usuario con ese token. Entonces, la pregunta es sobre cuál es la mejor estrategia para hacer eso.

Comprendo que nunca tendré el sitio 100% más seguro, pero puedo tomar algunas medidas comunes y hacer mi debida diligencia.

Parece una gran cantidad de explicaciones para algo que parece una pregunta fácil.

¡Gracias!

    
pregunta tjholmes66 12.09.2016 - 18:46
fuente

1 respuesta

1

Longitud de token de 256 bits, es de 42 caracteres en base64. Debe ser aleatorio.

El token generalmente se almacena en caché con la sesión del usuario. Por ejemplo, Redis. Cualquier otro método de almacenamiento haría y variará con la capacidad de respuesta, por ejemplo. obtener un JSON largo desde tmpfs y desde SQL DB es diferente. La compresión ayuda.

Este puede ser otro servicio local. Por ejemplo, el servicio de token que contiene claves de API.

    
respondido por el Aria 13.09.2016 - 00:32
fuente

Lea otras preguntas en las etiquetas