La autenticación basada en token no se trata de proteger la comunicación contra terceros atacantes. Es para asegurar el servidor contra el propio cliente .
De todos modos, para la seguridad adecuada necesitas SSL. Sin SSL, imagine un atacante activo , por ejemplo. ese friki barbudo de aspecto gracioso está sentado en dos mesas suyas en el mismo restaurante; no lo sabe, pero tiene un falso punto de acceso WiFi en su mochila, y actualmente está interceptando su tráfico de Internet, lo que usted cree para pasar por el restaurante "WiFi gratuito". Ese tipo puede secuestrar sus comunicaciones en cualquier momento. Él ve lo que envía a los sitios web y lo que recibe de estos sitios, y puede alterar ambos tipos de datos a voluntad. Cuando se ríe y casi se atraganta con su batido de leche, es porque está leyendo tus correos electrónicos.
Para derrotar a los atacantes activos, necesita algo que proteja la confidencialidad e integridad de los datos, y se asegure de hablar con el servidor correcto, no con Bearded-Geek-in-the-Middle . Y ese "algo" es SSL .
Con SSL, puede utilizar Autenticación básica HTTP . Esto funcionará ... siempre que desee utilizar la autenticación básica HTTP, ya que esa autenticación la maneja el navegador web, con su propia ventana emergente, que puede ser fea. Por ejemplo, puede verse así:
Lamayoríadelosdiseñadoreswebestánhorrorizadosporlapracticidadyelminimalismodeestaventanaemergente,querecuerdalosgloriososexperimentosarquitectónicosdelaeradeStalin.Porlotanto,casinadiehaceeso.Ensulugar,lossitioswebimplementansupropia"página de inicio de sesión", en HTML puro, y por lo tanto no pueden beneficiarse del soporte inherente de la autenticación básica por parte del navegador. Deben usar una cookie, es decir, el "token de autenticación" del que estamos hablando.
Además, la autenticación del usuario no se basa necesariamente en un inicio de sesión y una contraseña. Algunos sitios hacen cosas más divertidas, incluida la delegación de autenticación a otro servidor, utilizando el protocolo OAuth . Este mismo sitio, security.stackexchange.com , hace eso. Esto nuevamente requiere un cierto almacenamiento de datos en el navegador del cliente, los datos que no son un nombre de usuario y contraseña
.
Una vez que comience a almacenar datos en el navegador del cliente, puede imaginar almacenar datos que deban permanecer opacos para el usuario (si es que debe ser lo suficientemente inquisitivo para ver sus cookies) y que se oponga a las modificaciones del usuario. (Dependiendo de los datos y para qué se utiliza). Esto requiere, respectivamente, cifrado y integridad comprobada . Ese tipo de "seguridad" tiene que ver con almacenar cosas en el sistema cliente pero sin confiar en el sistema cliente.