Introducción
La autenticación basada en tokens es prominente en todas partes de la web hoy en día. Con la mayoría de las empresas web que utilizan una API, los tokens son la mejor manera de manejar la autenticación para varios usuarios.
Hay algunos factores muy importantes al elegir la autenticación basada en tokens para su aplicación. Las principales razones para los tokens son:
- Servidores escalables y sin estado
- Listos para aplicaciones móviles
- Pase la autenticación a otras aplicaciones
- Seguridad adicional
¿Quién usa la autenticación basada en Tokens?
Cualquier API o aplicación web importante que haya encontrado probablemente haya utilizado tokens. Aplicaciones como Facebook, Twitter, Google+, GitHub y muchas más usan tokens.
echemos un vistazo a cómo funciona exactamente.
Por qué surgieron los tokens
Antes de que podamos ver cómo funciona la autenticación basada en tokens y sus beneficios, tenemos que ver la forma en que se ha realizado la autenticación en el pasado.
Autenticación basada en servidor (El Método Tradicional)
Dado que el protocolo HTTP es sin estado, esto significa que si autenticamos a un usuario con un nombre de usuario y una contraseña, en la siguiente solicitud, nuestra aplicación no sabrá quiénes somos. Tendríamos que autenticarnos de nuevo.
La forma tradicional de que nuestras aplicaciones recuerden quiénes somos es almacenar la información del usuario que ha iniciado sesión en el servidor. Esto se puede hacer de varias maneras diferentes en la sesión, generalmente en memoria o almacenado en el disco.
A medida que la web, las aplicaciones y el auge de la aplicación móvil han surgido, este método de autenticación ha mostrado problemas, especialmente en la escalabilidad.
Los problemas con la autenticación basada en servidor
Surgieron algunos problemas importantes con este método de autenticación.
- Sesiones: Cada vez que un usuario se autentica, el servidor tendrá que crear un registro en algún lugar de nuestro servidor. Esto generalmente se hace en memoria y cuando hay muchos usuarios que se autentican, la sobrecarga en su servidor aumenta.Escalabilidad
- : Dado que las sesiones se almacenan en la memoria, esto genera problemas de escalabilidad. A medida que nuestros proveedores de nube comienzan a replicar servidores para manejar la carga de aplicaciones, tener información vital en la memoria de sesión limitará nuestra capacidad de escalar.
- CORS: Como queremos ampliar nuestra aplicación para permitir que nuestros datos se utilicen en múltiples dispositivos móviles, tenemos que preocuparnos por el intercambio de recursos de origen cruzado (CORS). Al usar llamadas AJAX para capturar recursos de otro dominio (móvil a nuestro servidor API), podríamos tener problemas con solicitudes prohibidas.
- CSRF: También tendremos protección contra la falsificación de solicitudes entre sitios (CSRF). Los usuarios son susceptibles a los ataques CSRF, ya que ya se pueden autenticar con, por ejemplo, un sitio bancario y esto se podría aprovechar al visitar otros sitios.
Con estos problemas, siendo la escalabilidad el principal, tenía sentido probar un enfoque diferente.
Cómo funciona la autenticación basada en Tokens
La autenticación basada en tokens es sin estado. No almacenamos ninguna información sobre nuestro usuario en el servidor o en una sesión.
Este concepto por sí solo se ocupa de muchos de los problemas de tener que almacenar información en el servidor.
La ausencia de información de sesión significa que su aplicación puede escalar y agregar más máquinas según sea necesario sin preocuparse por dónde ha iniciado sesión un usuario.
Aunque esta implementación puede variar, la esencia de la misma es la siguiente:
- El usuario solicita acceso con Nombre de usuario / contraseña
- La aplicación valida credenciales
- La aplicación proporciona un token firmado al cliente
- El cliente almacena ese token y lo envía junto con cada solicitud
- El servidor verifica el token y responde con datos
Cada solicitud requerirá el token. Este token debe enviarse en el encabezado HTTP para mantener la idea de solicitudes HTTP sin estado. También tendremos que configurar nuestro servidor para que acepte solicitudes de todos los dominios utilizando Access-Control-Allow-Origin: *. Lo interesante de designar * en el encabezado ACAO es que no permite que las solicitudes proporcionen credenciales como autenticación HTTP, certificados SSL del lado del cliente o cookies.
Una vez que nos hemos autenticado con nuestra información y tenemos nuestro token, podemos hacer muchas cosas con este token.
Incluso podríamos crear un token basado en permisos y pasarlo a una aplicación de terceros (por ejemplo, una nueva aplicación móvil que queramos usar), y ellos podrán tener acceso a nuestros datos, pero solo a la información que permitimos con ese token específico.
Los beneficios de los tokens
Sin estado y escalables
Los tokens se almacenan en el lado del cliente. Completamente sin estado y listo para ser escalado. Nuestros equilibradores de carga pueden pasar a un usuario a cualquiera de nuestros servidores, ya que no hay información de estado o sesión en ningún lugar.
Si tuviéramos que mantener la información de sesión de un usuario que ha iniciado sesión, esto requeriría que siguiéramos enviando a ese usuario al mismo servidor en el que inició sesión (llamado afinidad de sesión).
Esto trae problemas ya que algunos usuarios se verían forzados al mismo servidor y esto podría provocar un punto de tráfico pesado.
¡Sin embargo, no se preocupe! Esos problemas se han ido con los tokens, ya que el token en sí contiene los datos de ese usuario.
Seguridad
El token, no una cookie, se envía en cada solicitud y, como no se envía ninguna cookie, esto ayuda a prevenir ataques CSRF. Incluso si su implementación específica almacena el token dentro de una cookie en el lado del cliente, la cookie es simplemente un mecanismo de almacenamiento en lugar de uno de autenticación. ¡No hay información basada en sesiones que manipular, ya que no tenemos una sesión!
El token también caduca después de un período de tiempo establecido, por lo que se requerirá que el usuario inicie sesión una vez más. Esto nos ayuda a mantenernos seguros. También está el concepto de revocación de tokens que nos permite invalidar un token específico e incluso un grupo de tokens basados en la misma concesión de autorización.
Extensibilidad (Amigo de un Amigo y Permisos)
Los tokens nos permitirán crear aplicaciones que compartan permisos con otros. Por ejemplo, hemos vinculado cuentas sociales aleatorias a nuestras cuentas principales, como Facebook o Twitter.
Cuando iniciamos sesión en Twitter a través de un servicio (por ejemplo, Buffer), permitimos que Buffer publique en nuestra transmisión de Twitter.
Mediante el uso de tokens, así es como proporcionamos permisos selectivos a aplicaciones de terceros. Incluso podríamos crear nuestra propia API y entregar tokens de permiso especiales si nuestros usuarios quisieran dar acceso a sus datos a otra aplicación.
Múltiples plataformas y dominios
Hablamos un poco sobre CORS anteriormente. Cuando nuestra aplicación y servicio se expandan, tendremos que proporcionar acceso a todo tipo de dispositivos y aplicaciones (¡ya que nuestra aplicación definitivamente se volverá popular!).
Al tener nuestra API just serve data, también podemos elegir el diseño para servir activos desde una CDN. Esto elimina los problemas que CORS plantea después de establecer una configuración de encabezado rápida para nuestra aplicación.
Access-Control-Allow-Origin: *Nuestros datos y recursos están disponibles para solicitudes de cualquier dominio, siempre y cuando el usuario tenga un token válido.
Basado en estándares
Al crear el token, tiene algunas opciones. Nos adentraremos más en este tema cuando aseguremos una API en un artículo de seguimiento, pero el estándar a usar serían los tokens web JSON.
Este práctico gráfico de depurador y biblioteca muestra la compatibilidad con tokens web JSON. Puede ver que tiene una gran cantidad de soporte en una variedad de idiomas. Esto significa que en realidad podría cambiar su mecanismo de autenticación si decide hacerlo en el futuro!
Conclusión
Esto fue solo un vistazo al cómo y por qué de la autenticación basada en tokens. Como siempre es el caso en el mundo de la seguridad, hay mucho más en cada tema y varía según el caso de uso. Incluso nos adentramos en algunos temas de escalabilidad que también merecen su propia conversación.
Este fue un resumen rápido de alto nivel, así que no dude en señalar cualquier cosa que se haya perdido o cualquier pregunta que tenga sobre el asunto.
En nuestro próximo artículo, veremos la anatomía de los tokens web JSON.
Nota: Agregando información de encabezado ACAO y aclaraciones de CSRF (gracias a Emily Stark por la información del artículo)