Tipo de concesión Password Credentials en OAuth 2.0

El Tipo de Concesión Password Credentials, frecuentemente llamado el flujo "Resource Owner Password Credentials" (ROPC), es una forma para que los usuarios proporcionen directamente su nombre de usuario y contraseña para obtener un token de acceso. Las recomendaciones de seguridad actuales (RFC 9700) dicen que este tipo de concesión NO DEBE usarse, porque la aplicación cliente ve la contraseña del usuario. Todavía existe en sistemas antiguos, así que puedes encontrarlo al probar uno.

Qué introduces en LoadFocus

En una prueba de carga, establece Tipo de autorización en OAuth 2.0 y Grant Type en Password Credentials. El formulario tiene estos campos:

• Token Name: una etiqueta para ti. No se envía al servidor.
• Access Token URL: el endpoint de token del proveedor.
• Username, Password: la cuenta para la que se solicita el token. Usa una cuenta de prueba dedicada, no una personal.
• Client ID, Client Secret, Scope, Audience: tal como los emite o acuerda tu proveedor (Audience es específico de cada proveedor).

Antes de que empiece la prueba, LoadFocus envía una solicitud POST por HTTPS a la Access Token URL, con los campos anteriores como cuerpo JSON, y lee access_token de la respuesta JSON. El RFC 6749 describe un cuerpo codificado como formulario, así que si tu proveedor rechaza la solicitud, comprueba si su endpoint de token acepta JSON.

¿Cómo Funciona Password Credentials?

1. Entrada del Usuario:

• El usuario proporciona su nombre de usuario y contraseña directamente a la aplicación cliente.

2. Solicitud del Token:

• El cliente entonces envía estas credenciales al endpoint de token del servidor de autorización. Esta solicitud también típicamente incluye el client_id y client_secret del cliente, aunque algunas implementaciones podrían no requerir el secreto del cliente para este flujo.

3. Respuesta del Token:

• Si las credenciales son válidas, el servidor de autorización responde con un token de acceso (y posiblemente un token de actualización). El cliente puede entonces usar este token para hacer solicitudes en nombre del usuario al servidor de recursos.

¿Cómo Configurar Password Credentials?

1. Registrar Tu Aplicación:

• Como con otros flujos OAuth 2.0, comienza registrando tu aplicación con el proveedor OAuth 2.0. Generalmente recibirás un client_id y client_secret después del registro.

2. Mecanismo de Entrada:

• Implementa un mecanismo en tu aplicación cliente donde los usuarios puedan ingresar su nombre de usuario y contraseña. Esto podría ser un formulario de inicio de sesión simple.

3. Solicitud de Token:

• Cuando los usuarios proporcionan sus credenciales, tu aplicación debe hacer una solicitud POST al endpoint de token del servidor de autorización. Esta solicitud debe incluir el grant_type (establecido en "password"), username, password, client_id, y posiblemente client_secret. Asegúrate de que esta solicitud se haga de forma segura usando HTTPS.

4. Manejar la Respuesta del Token:

• Si las credenciales son correctas, el servidor de autorización responderá con un token de acceso, que tu aplicación debe almacenar de forma segura. Opcionalmente, también podrías recibir un token de actualización, que puede usarse para obtener nuevos tokens de acceso cuando el actual expire.

5. Usar el Token:

• Como con otros tipos de concesión, una vez que tengas un token de acceso, puedes usarlo para hacer solicitudes autorizadas al servidor de recursos en nombre del usuario.

6. Renovación del Token:

• Si recibiste un token de actualización y el token de acceso expira, usa el token de actualización para obtener un nuevo token de acceso sin pedir al usuario sus credenciales nuevamente.

Consideraciones:

• Preocupaciones de Seguridad: Este tipo de concesión implica compartir la contraseña real con el cliente, lo cual es un riesgo de seguridad significativo. Es esencial asegurar que el cliente sea completamente confiable.

• No lo uses en sistemas nuevos: el RFC 9700 dice que esta concesión NO DEBE usarse. Si controlas el sistema, pasa a la concesión Authorization Code (con PKCE) o a Client Credentials para llamadas de servicio a servicio.

Conclusión:

El Tipo de Concesión Password Credentials es sencillo, pero expone la contraseña del usuario al cliente y las recomendaciones actuales indican no usarlo. Úsalo en una prueba solo cuando el sistema que pruebas aún lo requiera, y limita las credenciales a una cuenta de prueba dedicada.