Entrar con el CLI

Implementado en identity-svc y en el CLI styx. Falta la pantalla /link de la web (el sitio donde se escribe el código): hasta que exista, el código se aprueba desde otra sesión con styx device approve. Las API keys son las mínimas (personales, con scopes y caducidad); las cuentas de servicio, la rotación y el canje en un gateway son el hito track/identity/api-keys.

Entrar: styx loginCopiar enlace

styx login --server https://styx.example.com

El CLI usa el device authorization grant (RFC 8628) con client_id = styx-cli:

1. Pide un código a POST /auth/device/code y lo muestra: ocho dígitos (4821 0937) y la dirección de verificación.
2. Sondea POST /auth/device/token respetando el interval del servidor. Si sondea demasiado rápido, el servidor contesta slow_down y el CLI espera 5 s más.
3. Quien tiene sesión en Styx aprueba el código (en la web, cuando exista /link, o con styx device approve). Al aprobarse, el CLI recibe un access token y un refresh token de dispositivo y los guarda.

El código caduca a los 10 minutos y sirve una sola vez. El servidor solo guarda el SHA-256 del device_code. Con --no-browser no se intenta abrir el navegador; --scope asset:play pide solo esos permisos.

Qué permisos recibe el dispositivoCopiar enlace

Los permisos de un dispositivo son la intersección de lo que pidió, lo que quien aprueba decide conservar y lo que el rol de quien aprueba concede. Nunca recibe más que quien lo aprueba. Una sesión de dispositivo con --scope no puede ejercer nada fuera de esos scopes aunque su rol lo permita, ni pasar una ruta que exija un rol (role:admin).

La sesión del dispositivo hereda el auth_time de quien la aprobó: aprobar desde una sesión vieja no da un login reciente al CLI.

Las sesiones de dispositivo tienen su propio tope (IDENTITY_MAX_DEVICE_SESSIONS_PER_ACTOR, 5): conectar un dispositivo nuevo solo desaloja a otro dispositivo, nunca a una sesión del navegador. El quick connect de la TV usa otro cliente (styx-tv) con un techo de permisos más estrecho: ver Conectar la TV y el CLI.

Dónde se guardan las credencialesCopiar enlace

En $XDG_CONFIG_HOME/styx/credentials.json (por defecto ~/.config/styx/): fichero 0600 en un directorio 0700, escrito de forma atómica. Un fichero con permisos más abiertos se rechaza (arréglalo con chmod 600 o vuelve a iniciar sesión). El keyring del sistema (Keychain, Secret Service) no está todavía: el fichero es el respaldo que prevé dec-0125 §10.5.

El servidor tiene que ser https://; http:// solo se admite en loopback (desarrollo). El CLI no sigue redirecciones.

Quién soy y salirCopiar enlace

styx whoami           # actor, rol, tipo de credencial (device|pat), scopes y caducidad
styx whoami --json
styx logout           # revoca la sesión en el servidor y borra el fichero

styx logout revoca la sesión en el servidor (no solo borra el fichero). Si el servidor no responde, borra el fichero igualmente y sale con error AUTH_NETWORK para que sepas que la sesión sigue viva hasta que caduque; --local salta la llamada.

Aprobar un dispositivo desde otra sesiónCopiar enlace

styx device approve 48210937 --yes [--scope asset:play]
styx device deny 48210937

Antes de aprobar, el CLI enseña lo mismo que enseñaría la web (nombre y tipo del dispositivo, cuándo y desde qué IP se pidió, scopes) y exige --yes: aprobar es un acto explícito. Cada consulta o decisión cuenta contra un presupuesto por sesión y por cuenta (5 por minuto y 20 por hora): con ocho dígitos, ese límite es lo que hace imposible adivinar un código ajeno.

API keys personalesCopiar enlace

styx token create --name ci --scope asset:play --expires 30d   # el secreto sale una vez, por stdout
styx token list
styx token revoke <id> --yes

• Formato styx_pat_ + 38 caracteres base62 (32 aleatorios y 6 de CRC32). Se guarda el SHA-256; el secreto no se puede volver a leer.
• Scopes obligatorios, un subconjunto de tus permisos de ahora. api-key:* no se puede delegar: una key nunca crea, lista ni revoca keys.
• Caducidad obligatoria (30 días por defecto, 90 como máximo, configurable en el servidor).
• Crear una key exige un login reciente (15 minutos).
• Cada key se canjea por un access JWT de 5 minutos como máximo (POST /auth/token, RFC 8693). El canje se rechaza si llega con Cookie, Origin o Sec-Fetch-*: una key pegada en una página web no sirve. Revocar la key corta el acceso en la siguiente comprobación; degradar a la cuenta degrada a sus keys.

Para CI y agentes:

echo "$KEY" | styx login --with-token --server https://styx.example.com   # por stdin, nunca por argv
STYX_SERVER=https://styx.example.com STYX_API_KEY_FILE=/run/secrets/styx styx whoami --json

STYX_API_KEY_FILE es mejor que STYX_TOKEN: el secreto no queda en el entorno del proceso.

AuditoríaCopiar enlace

Quedan en el audit de seguridad (sin secretos): device_code_issued, device_approved, device_denied, device_token_issued, device_code_guessing, api_key_created, api_key_revoked, api_key_exchanged y api_key_rejected (con el motivo: formato, desconocida, caducada, revocada, contexto de navegador).