# Inicio de sesión de usuarios de prueba con keenauth test login

`keenauth test login` inicia sesión de un usuario de prueba en un entorno `development` e imprime los tokens, para que pueda llamar a su API o probar su backend sin hacer clic en la página de inicio de sesión. Pasa por el inicio de sesión alojado real, del mismo modo que lo haría un navegador, y usa el código fijo de desarrollo `424242` (véase [Usuarios y mensajes de prueba en entornos que no son de producción](/docs/guides/test-environments)).

El comando no necesita clave de API ni una sesión de `keenauth login`: inicia sesión con el usuario de prueba, no con usted.

## Antes de empezar

- **Un usuario de prueba.** La dirección debe incluir la etiqueta `+test` en la parte local, por ejemplo `ada+test@example.com` o `ada+test_1@example.com`. Cree primero el usuario, por ejemplo con `keenauth users create --email ada+test@example.com`. El comando rechaza cualquier otra dirección antes de enviar una solicitud y termina con el código 2.
- **Una aplicación pública.** Indique el ID de una aplicación nativa o de página única del entorno con `--client-id`. La aplicación debe permitir el inicio de sesión con un código de correo electrónico (sin contraseña, `email_otp`).
- **Un URI de redirección.** De forma predeterminada, el comando usa `http://127.0.0.1:<puerto aleatorio>/callback`. Registre `http://127.0.0.1/callback` para la aplicación: un URI de redirección de bucle local acepta cualquier puerto (RFC 8252). Nada escucha en esa dirección; el comando lee la redirección por sí mismo. Para usar otro URI de redirección registrado, indíquelo con `--redirect-uri`.
- **El emisor del entorno.** Indíquelo con `--issuer` o defina `KEENAUTH_ISSUER`, por ejemplo `https://acme-dev.keenauth.app`.

## Uso

```sh
export KEENAUTH_ISSUER=https://acme-dev.keenauth.app
keenauth test login --user ada+test@example.com --client-id app_01j9z3k4m5n6p7q8r9s0t1v2w3
```

| Opción | Descripción |
|---|---|
| `--user` | Dirección de correo electrónico del usuario de prueba (obligatoria). |
| `--client-id` | ID de una aplicación pública del entorno (obligatorio). |
| `--issuer` | URL del emisor del entorno. Predeterminado: la variable de entorno `KEENAUTH_ISSUER`. |
| `--scope` | Ámbitos que se solicitan, separados por espacios. Predeterminado: `openid profile email`. Añada `offline_access` para recibir un token de actualización. |
| `--resource` | Indicador de recurso de la API para la que es el token de acceso (RFC 8707). |
| `--redirect-uri` | Un URI de redirección registrado para la aplicación. |
| `--output`, `-o` | `json`, `yaml` o `table`. Sin esta opción, la CLI muestra una tabla en un terminal y JSON en caso contrario. |

La salida contiene `token_type`, `access_token`, `id_token` (cuando se solicita `openid`), `refresh_token` (solo cuando se solicita `offline_access`), `expires_in` y `scope`. Trate los tokens como contraseñas: actúan como el usuario de prueba hasta que caducan. El comando los escribe en la salida estándar y en ningún otro lugar, y nunca muestra el código.

```sh
ACCESS_TOKEN=$(keenauth test login --user ada+test@example.com --client-id app_01j9z3k4m5n6p7q8r9s0t1v2w3 -o json | jq -r .access_token)
curl -H "Authorization: Bearer $ACCESS_TOKEN" http://localhost:3000/api/orders
```

## Qué hace el comando

1. Lee el documento de descubrimiento del entorno y abre una solicitud de autorización con PKCE (`S256`), `state` y `nonce`.
2. En el inicio de sesión alojado, introduce la dirección, solicita un código de correo electrónico y envía `424242`. Si el entorno pide después un código de correo electrónico como segundo factor, pide ese código y envía `424242` de nuevo.
3. Sigue la redirección de vuelta al URI de redirección, comprueba `state` e `iss`, e intercambia el código de autorización en el endpoint de tokens.
4. Comprueba que el ID token lo emitió el emisor para su aplicación con el `nonce` de la solicitud, e imprime los tokens.

El comando se detiene con un error cuando el inicio de sesión requiere algo distinto, por ejemplo una contraseña, una clave de acceso, una aplicación autenticadora, Single Sign-On empresarial para el dominio de la dirección, una página de consentimiento o la elección de una organización.

## Entornos

Solo los entornos `development` aceptan el código fijo. Use el comando únicamente con un entorno de desarrollo:

- En `staging`, no se envía nada a las direcciones de prueba, pero el código fijo se rechaza (`401 invalid_credentials`).
- En `production`, una dirección `+test` es una dirección ordinaria: el código de correo electrónico se envía de verdad a ella, y el código fijo se rechaza.

Cuando el servidor rechaza un paso, la CLI imprime su respuesta de problema sin cambios (`error`, `code`, `status`, `detail`, `request_id`), por ejemplo `code: test_feature_not_in_production`.

## Códigos de salida

| Código | Significado |
|---|---|
| `0` | El usuario de prueba ha iniciado sesión; se imprimen los tokens. |
| `1` | El inicio de sesión falló: un error de OAuth, una discrepancia de `state`, `iss` o `nonce`, o un paso que el comando no puede completar. |
| `2` | Error de uso: la dirección no tiene la etiqueta `+test`, falta una opción obligatoria o el emisor, o un valor no es válido. No se envió ninguna solicitud. |
| `3` | El servidor respondió `401` o `403`, por ejemplo `invalid_credentials` o `test_feature_not_in_production`. |