Invitar a alguien a tu servidor o a tu hogar con un enlace o un código, con caducidad, usos, bibliotecas y rol.
Implementado en parte. Funciona la invitación simple: un admin crea invitaciones de un solo uso con caducidad, el invitado la canjea durante el login con su proveedor OIDC (passkey) y el admin las lista y revoca, por la API de identity-svc y con
styx invite. Siguen especificados y sin implementar (dec-0125§7): bibliotecas concedidas, hogares, transferir un perfil, usos múltiples, código corto, QR, duración de cuenta, el asistente y la lista de Admin → Invitaciones en la web, la página/joiny el onboarding. Lo que dice esa parte obliga a la implementación.
Con styx invite create (hace falta un access token de admin u owner con un login reciente,
en un fichero: --token-file):
| Opción | Qué hace |
|---|---|
--expires | obligatoria (90m, 24h, 7d); el tope lo fija IDENTITY_INVITE_MAX_TTL_S (7 días) |
--role | member por defecto o restricted. admin lo da la configuración y owner, nunca |
--email | opcional: sólo entra quien llegue del proveedor con ese email |
--note | opcional, para reconocerla en la lista |
export STYX_IDENTITY_URL=https://identity.example.org
styx invite create --expires 7d --email ana@example.org --return-to https://styx.example.org/ --yesEs de un solo uso. El resultado es el token (styx_inv_…) y, con --return-to, el enlace de
entrada. El token sólo se muestra aquí: identity guarda su hash. Crearla pide --yes porque da
acceso al nodo. Hay un tope de invitaciones creadas por hora y de invitaciones activas a la vez.
/auth/oidc/start?returnTo=…&invite=…) o, antes, lo inspecciona con
echo "$TOKEN" | styx invite inspect - (por la entrada estándar: como argumento queda en el historial del shell): rol, caducidad y si va ligada a un email, sin consumirla.La invitación se consume en el mismo paso en que se crea la cuenta: dos personas no pueden gastar el
último uso a la vez, y nadie puede hacer que otra persona canjee una invitación suya. Una identidad
que ya tiene cuenta no la canjea (IDENTITY_ACCOUNT_EXISTS) ni consume el uso: una invitación
nunca cambia el rol de una cuenta existente.
El rol de la cuenta nueva es el de la invitación con IDENTITY_ROLE_SOURCE=config+db (por defecto);
con config nace restricted. Si las listas de configuración (IDENTITY_*_SUBJECTS) nombran esa
identidad, mandan ellas.
Atención: quien entra en el proveedor OIDC sin el enlace de invitación recibe una cuenta
restricted, y desde ese momento toda invitación para esa identidad devuelve
IDENTITY_ACCOUNT_EXISTS. Para subirla hay que nombrarla en las listas de configuración y reiniciar.
Con una invitación ligada a un email, el proveedor debe enviar email_verified: true.
styx invite list [--status active|exhausted|expired|revoked] muestra estado, usos y caducidad;
styx invite show <id>, además, las cuentas creadas con ella. styx invite revoke <id> --yes la
inutiliza (idempotente). Revocar una invitación no afecta a las cuentas ya creadas con ella; borrar
esas cuentas es una acción aparte.
Todo queda en el audit de seguridad: invite_created, invite_redeemed, invite_rejected e
invite_revoked, sin el token.
Bibliotecas, hogares y transferencia de perfil, usos múltiples, código corto y QR, duración de la
cuenta, el onboarding y la gestión desde la web: ver dec-0125 §7 y §13.