Autenticación de cliente vs. autenticación de usuario

11

Actualmente estoy buscando protocolos de autenticación que funcionen bien con la API REST, en java. Hay algo fundamental que no entiendo: leí mucho material sobre el protocolo OAuth, SSL, autenticación HTTP básica, compendio, etc. Y en todos ellos hay aparentemente significados diferentes del término "cliente". En la mayoría, a mi entender, este término significa aplicación web o el navegador. Pero en algunos, por ejemplo, la autenticación HTTP básica, este término se refiere al propio usuario.

No entiendo exactamente cómo puede o debe ser autenticada una instancia de una aplicación web. Sé que hay certificados involucrados en el proceso, pero como lo veo, solo se encargan de transferir de forma segura el mensaje al servidor, y evitan la reproducción y los ataques MITM. En OAuth, debe haber un token en el certificado, después de un intercambio de nombre de usuario y contraseña, pero como el nombre de usuario y la contraseña pertenecen al usuario, según entiendo, ¿dónde está la parte que autentica al cliente?

Hay algunos protocolos que utilizan claves privadas y públicas en el lado del servidor, así como en el lado del cliente, que realmente se aseguran de que el cliente sea "quien dice que es". Pero, ¿estas claves deben aplicarse a cada instancia de esta aplicación web? Estoy confundido.

¿En qué casos, de todos modos, necesitaremos la autenticación del cliente? ¿No es suficiente autenticar al usuario y cuidar la integridad del mensaje?

    
pregunta rita potter 04.04.2013 - 15:45
fuente

2 respuestas

8

El cliente es un concepto de red: los datos se transportan entre dos máquinas, el servidor y el cliente . El cliente es quien inicia la conversación; el servidor es el que está sentado todo el día, esperando que los clientes se conecten.

El usuario es la entidad biológica (presumiblemente humano) que controla al cliente. La autenticación se trata del servidor, asegurándose de que todo lo que recibe se origine de un usuario específico. Sin embargo, el servidor no está hablando con el usuario (el ser humano) sino con el cliente (la computadora del usuario). Cuando un servidor autentica al usuario a través de una cookie HTTP almacenada, realmente autentica al cliente : dado que el valor de la cookie se envió previamente a un cliente específico, solo ese cliente puede mostrar el valor exacto de la cookie. El servidor entonces asume que un cliente dado está bajo control exclusivo de su supuesto propietario humano, y luego se siente contento de que el usuario humano haya estado involucrado.

La distinción entre cliente y usuario se hace evidente cuando la máquina del usuario se subvierte (por ejemplo, infectada por malware). La máquina comenzará a hacer cosas fuera del control del usuario humano.

Para hacer una analogía, si tienes un perro y ese perro me muerde, te demandaré a , no al perro, porque se supone que el perro está bajo tu control. Incluso si el perro contrae rabia (explicando su comportamiento vindicativo), sigue siendo su responsabilidad. En ese sentido, autenticar al perro es tan bueno como autenticarlo (al menos a los ojos de mis abogados) y depende de usted asegurarse de que su perro esté realmente bajo su control exclusivo.

Con las aplicaciones web y la "API", la imagen puede volverse más compleja, ya que el servidor también puede comportarse como un cliente con respecto a otro servidor. Ese servidor secundario puede querer asegurarse de la identidad del primer servidor, del usuario humano que inició el proceso completo o de ambos. La terminología puede ser fuente de confusión si se reutilizan los mismos términos.

Cuando se usan pares de claves públicas / privadas, el propietario de la clave privada (la máquina que contiene la clave privada) la utiliza para realizar algunos cálculos que se vinculan con otro cálculo que involucra la clave pública. Por ejemplo, con firmas digitales , el propietario de la clave privada genera una firma sobre un mensaje determinado ( una secuencia de bytes); la firma se puede verificar utilizando la clave pública. Las firmas digitales son una buena herramienta para la autenticación: al calcular una firma en un desafío enviado por un verificador, el propietario de la clave privada demuestra a ese verificador su dominio de la clave privada. De este modo, el verificador obtiene una garantía de que realmente está hablando con "quien controla la clave privada correspondiente a una clave pública determinada". La parte interesante del proceso es que el verificador no necesita conocer la clave privada para eso, por lo que es posible verificar una firma sin tener el poder de generar firmas.

    
respondido por el Thomas Pornin 04.04.2013 - 16:09
fuente
4

En OAuth, hay tres partes, el propietario del recurso (el usuario), el cliente (la aplicación que se autentica con y el servidor de recursos (el servidor que realmente valida las credenciales del usuario). El cliente es la aplicación web porque el servidor de recursos para verificar (y posiblemente proporcionar detalles sobre) el propietario del recurso (usuario) que está intentando iniciar sesión.

Es importante autenticar al cliente para varios modos de OAuth porque los detalles sobre el usuario y posiblemente incluso los permisos para usar la cuenta del usuario en el servidor de recursos se otorgarán a la aplicación web (cliente).

El uso de los términos es confuso ya que cliente a menudo es sinónimo de usuario, pero en el caso de OAuth, es simplemente la forma en que eligen la terminología.

En otros sistemas, la distinción entre cliente y usuario puede significar si la computadora que se está conectando está verificada o la persona que la usa. Algunos mecanismos de autenticación están diseñados para verificar el hardware en lugar de los usuarios. Un sistema informático, por ejemplo, podría tener un certificado privado compartido por varios usuarios que verifique que el cliente que se está utilizando es un equipo determinado, pero no proporcionaría detalles sobre el usuario de ese equipo.

    
respondido por el AJ Henderson 04.04.2013 - 15:59
fuente

Lea otras preguntas en las etiquetas