Autenticación de sesión vs Autenticación de token

1. En Autenticación basada en sesión el servidor hace todo el trabajo pesado del lado del servidor. En términos generales, un cliente se autentica con sus credenciales y recibe un session_id (que puede almacenarse en una cookie) y lo adjunta a cada solicitud saliente posterior. Por lo tanto, esto podría considerarse un "token" ya que es el equivalente de un conjunto de credenciales. Sin embargo, no hay nada especial en esta session_id-String. Es solo un identificador y el servidor hace todo lo demás. Es un estado Asocia el identificador con una cuenta de usuario (por ejemplo, en la memoria o en una base de datos). Puede restringir o limitar esta sesión a ciertas operaciones o un cierto período de tiempo y puede invalidarla si existe un problema de seguridad y, lo que es más importante, puede hacer y cambiar todo esto sobre la marcha. Además, puede registrar a los usuarios cada movimiento en el (los) sitio (s) web. Las posibles desventajas son una mala capacidad de escala (especialmente en más de una granja de servidores) y el uso extensivo de memoria.

2. En Autenticación basada en token , ninguna sesión se mantiene en el lado del servidor (sin estado). Los pasos iniciales son los mismos. Las credenciales se intercambian por un token que luego se adjunta a cada solicitud posterior (también se puede almacenar en una cookie). Sin embargo, con el propósito de disminuir el uso de la memoria, la capacidad de escalado y la flexibilidad total (los tokens se pueden intercambiar con otro cliente) se emite una cadena con toda la información necesaria (el token) que se verifica después de cada solicitud realizada por el cliente al servidor. Hay varias formas de usar / crear tokens:

a) utilizando un mecanismo hash, por ejemplo, HMAC-SHA1

token = user_id|expiry_date|HMAC(user_id|expiry_date, k)

--id y expiry_id se envían en texto sin formato con el hash resultante adjunto (k solo lo sabe el servidor)

b) cifrar el token de manera simétrica, por ejemplo, con AES

token = AES(user_id|expiry_date, x)

--x representa la clave de en- / descifrado

c) cifrarlo de forma asimétrica, p. con RSA

token = RSA(user_id|expiry_date, private key)

Los sistemas productivos suelen ser más complejos que esos dos arquetipos. Amazon, por ejemplo, utiliza ambos mecanismos en su sitio web. También se pueden usar híbridos para emitir tokens como se describe en 2 y también asociar una sesión de usuario con él para el seguimiento o posible revocación del usuario y aún así conservar la flexibilidad del cliente de tokens clásicos. Asimismo, OAuth 2.0 usa tokens de portador de corta duración y específicos y tokens de actualización de mayor duración, p. Ej. para obtener fichas de portador.

Fuentes:

• enlace
• enlace

• enlace

• Desmitificando la autenticación web (Cookies de sesión sin estado)

• enlace

HTTP no tiene estado, y para tener un estado autenticado, necesita algún tipo de token utilizado para hacer referencia a la información sobre el usuario. Este identificador de sesión suele tener la forma de un token aleatorio enviado como un valor de cookie. Se utiliza un Token de acceso de OAuth para identificar a un usuario y el scope de recursos a los que tiene acceso. En las aplicaciones que utilizan el inicio de sesión único de OAuth, un token de acceso de OAuth generalmente se intercambia por un identificador de sesión que puede hacer un seguimiento de una variedad más amplia de estados de usuarios.

Desde la perspectiva de un atacante, secuestrar un identificador de sesión o un token de acceso OAuth es tan bueno como un nombre de usuario y una contraseña, y algunas veces es incluso mejor. Los ID de sesión deben tener propiedades de seguridad que protejan las cuentas de usuario contra el compromiso.

Desde la perspectiva del desarrollador, nunca reinvente la rueda . Utilice el administrador de sesión provisto por su plataforma y asegúrese de que esté configurado para cumplir con el OWASP Session Management Guidelines .

Entonces, en la autenticación basada en sesión, para aumentar la seguridad en el acceso a los recursos, se requiere uno:

• Se debe utilizar como un reemplazo para la credencial de un usuario
• Siempre debe usar una cookie persistente
• Debe identificar a los usuarios que regresan al sitio web
• Debería usar autenticación de 2 factores