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).

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

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

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.

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