Reenviar su nombre de usuario y contraseña es un riesgo de seguridad mucho mayor y no tiene beneficios sobre los identificadores de sesión (o alguna variación de tokens de acceso) que puedo ver.
Perder una contraseña tiene un mayor impacto
Aquí se explica por qué: si tu ID de sesión está secuestrada, tu atacante tendrá acceso a tu sesión, lo cual es lo suficientemente malo. Pero si obtiene su nombre de usuario y contraseña, puede hacerse pasar por usted al servicio todo el tiempo que quiera (porque generalmente las contraseñas no caducan, a diferencia de las sesiones), puede restablecer su contraseña y bloquearlo fuera del servicio, etc. Dado que muchas personas reutilizan contraseñas en otros sitios, la obtención de su contraseña también puede comprometer sus cuentas en otros muchos sitios. No puede hacer nada de eso si solo tiene el ID de sesión. Por lo tanto, es mejor exponer el ID de sesión de corta duración, localizado al riesgo que el nombre de usuario y la contraseña de larga duración.
Lo ideal es que la contraseña nunca se transmita a través de la red (existen esquemas que evitan el envío de la contraseña y la mayoría de los navegadores y servidores web son capaces de usar los más simples (por ejemplo, la autenticación de Google Digest), pero desafortunadamente , el desarrollo de esta tecnología se ha descuidado a favor de implementar sistemas de inicio de sesión del lado del servidor utilizando pantallas de inicio de sesión atractivas, que requieren la transmisión de la contraseña.)
El secuestro de la sesión es (debería ser ...) difícil
Robar un ID de sesión no es tan fácil. Adivinar los ID de sesión es muy difícil (billones de veces más difícil que adivinar la contraseña promedio) si la aplicación que los genera lo está haciendo bien. Los ID de sesión deben crearse como cadenas aleatorias largas utilizando un generador de números aleatorios de fuerza criptográfica; y como la mayoría de las sesiones solo son válidas durante unas pocas horas como máximo, no hay mucho tiempo para hacer muchas conjeturas. Pasar los identificadores de sesión como parámetros GET en la URL es un problema, sí, pero esto debe hacerse solo para degradarse con gracia cuando el navegador del usuario no acepta cookies. La mayoría de los identificadores de sesión se pasan utilizando cookies que se encuentran en el encabezado de una solicitud http.
Autenticación y autorización federada
Finalmente, reenviar el nombre de usuario y la contraseña a menudo es simplemente imposible, ya que pueden no estar disponibles. Si utiliza la autenticación federada y sistemas de autorización como OpenID / OAuth, no tiene acceso a las credenciales del usuario; acaba de obtener un token de acceso o identificación (o ambos), que son una clase de carta notariada para demostrar que usted es quien dice ser y debe tener acceso a un determinado recurso. Nuevamente, los tokens de acceso solo son válidos por unos pocos minutos hasta una hora, y solo para un recurso específico, por lo que incluso si un token de acceso fue robado, el daño que alguien podría hacer con él sería limitado.
Con OAuth, puede solicitar un tipo especial de token llamado token de renovación que puede usar para obtener un token de acceso nuevo sin la necesidad de que el usuario vuelva a iniciar sesión cuando el token de acceso anterior caduque. Así que esto se acerca a su pregunta acerca de cómo reenviar las credenciales de inicio de sesión, porque si el token de renovación es robado, el atacante obtiene acceso casi indefinido al servicio para el cual está destinado el token. Pero tenga en cuenta que incluso cuando se roba un token de renovación (que normalmente se mantiene fuera del alcance de los agentes de usuario por parte de un servidor), esto no compromete la contraseña del usuario y todos los demás sitios para los que usa su cuenta.
APIs descansadas
A diferencia de los sitios web que permiten que un usuario inicie sesión, las API suelen ser sin estado. Por lo tanto, el cliente debe autenticarse con cada solicitud que haga a la API. Esto se puede hacer enviando el nombre de usuario y la contraseña cada vez que realice una solicitud, pero muchas API lo resuelven haciendo que un cliente obtenga primero un token de acceso con sus credenciales, y luego use el token de acceso para acceder la API. OAuth es un ejemplo perfecto para esto. De nuevo, la contraseña solo se envía una vez por "sesión" para obtener un token de acceso.