¿Dónde se almacena el token de autenticación en el lado del cliente?

Question

Quiero alojar un proyecto de la API web de MVC 4 en Azure. Necesito asegurarme de que se pueda acceder a las API desde cualquier aplicación de terceros y desde cualquier navegador. Implementar una API RESTful que simplemente devuelve JSON me parece una buena idea. Ahora, el mayor desafío para mí es crear un mecanismo de autenticación independiente de la plataforma. No quiero usar el MembershipProvider predeterminado. Estaré usando SSL. Tampoco usaré FormsAuthentication. Todas las llamadas API se realizarán a través de JQuery/AJAX.

Estoy tratando de entender la autenticación basada en tokens. Esto es lo que pensé que podía hacer: - El cliente envía sus credenciales de usuario al servidor a través de HTTPS - El servidor autentica el cliente, crea un token, lo guarda en el DB junto con un sello de fecha y hora y un período de vencimiento, y lo envía volver al cliente - El cliente envía el token al servidor cada vez que accede a una API

Ahora, la parte que no entiendo es, ¿dónde almacena el cliente el token? ¿Se guarda en una cookie? Si es así, ¿dónde guardan las aplicaciones de terceros que no son del navegador el token de autenticación? ¿Con qué facilidad es robado el token?

Answer 1

El token de autenticación se almacena en cookie por el proveedor de membresía ASP.net y el módulo de autenticación. En el lado del cliente, la biblioteca del cliente HTTP puede tratar con las cookies. La autenticación sin cookies también es posible con la autenticación de formularios. Si el canal no está encriptado (ssl o https), entonces el token puede ser robado por los rastreadores intermedios. Secure websapps establece un pequeño tiempo de espera para la cookie de autenticación, de modo que un pequeño período de inactividad vencerá la sesión y, por lo tanto, la cookie.

Sin embargo, para la autenticación API, el mecanismo de autenticación puede ser diferente. Cada llamada puede autenticarse de forma independiente. Por lo tanto, no es necesario mantener un token para el cliente. El encabezado Authorization para cada llamada API debe tener algún secreto que el servidor pueda identificar. Amazon AWS usa este estilo de autenticación API y muchos otros siguieron este estilo. Con webapi puedes implementar este tipo de autenticación.

1. El cliente tiene una clave privada para su cuenta emitida por el servidor o importada al servidor por la cuenta por el usuario.

2.El cliente llama a la API como de costumbre, pero pone algo de información en el encabezado Autorización. La información sería HMAC de los datos enviados junto con la identificación de la cuenta del cliente y la fecha.

Así es como el encabezado de autorización HTTP API debe ser similar

Authorization: account-id HMAC_OF_WITH_SECRET_KEY(data + account-id + GMT Date that will be in date header) 

3.En el lado del servidor (lado WebAPI) es necesario tener por encargo AuthorizeAttribute para los controladores WebAPI. Estas autenticaciones personalizadas recibirán las solicitudes del cliente y harán lo contrario de lo que ha hecho el cliente. El servidor tiene una clave privada de cliente y puede organizar los datos tal como lo hizo el cliente y volver a calcular el HMAC. Si este HMAC es el mismo que el de lo que se envía en el encabezado Autorización, entonces se autentica al cliente para la cuenta o la identificación del usuario. Tenga en cuenta que el encabezado de autorización tiene el secreto de cuenta + HMAC secreto. Entonces, al usar la identificación de la cuenta o la identificación del usuario en este servidor de encabezado, se puede saber qué cliente está solicitando.

Este mecanismo cubre la autenticación y la integridad de datos.

Answer 2

El cliente necesita almacenar el token de forma segura en su espacio de aplicación. Puede elegir cifrar aún más el token.

La cookie también es un lugar para almacenar tokens, pero el problema es que algunos clientes no tienen la ventaja de las cookies. Entonces piensa en el caso general.