Traducción. Autoritativo: ../../../modules/identity/prd.md.
identity es cómo la plataforma sabe quién está preguntando y si puede. Guarda al personal de
nuestros clientes, los roles que llevan, las máquinas que actúan por ellos, y el provider OAuth2
que permite a un tercero integrarse sin tocar jamás una contraseña. Todo endpoint de la suite está
gateado por algo definido acá.
Para quién es
El problema hoy
El control de acceso es la parte de una plataforma B2B por la que los clientes no preguntan hasta que falla, y entonces es lo único por lo que preguntan. Tres fallas concretas, porque el diseño existe para evitarlas. Roles que en realidad son un interruptor. Muchas plataformas entregan “admin” y “member” y ahí paran. Apenas un tenant tiene una agencia, un call center y un equipo de finanzas tocando la misma cuenta, ese modelo los obliga a otorgar de más. Nuestro modelo de permisos es por acción desde el inicio (DEC-D5), así que “puede leer contactos pero no sus documentos” es expresable y no una aspiración. Integraciones que piden una contraseña. Sin un provider OAuth2, un tercero que se integra le pide al tenant una API key con todo, o peor, credenciales de consola. Ser provider OAuth2 es lo que hace posible un ecosistema de integraciones sin eso. Acceso de soporte que nadie puede auditar. Los operadores necesitan ver lo que ve el tenant. Hecho a la ligera, eso es una lectura indetectable de los datos de todos los clientes. Con ventana de tiempo, razón obligatoria, auditoría y visibilidad para el tenant, pasa de ser un pasivo a ser una señal de confianza.Qué hace (normativo)
- Guarda organizaciones y usuarios, donde el email de un usuario es único por organización.
La misma persona trabajando con dos de nuestros clientes tiene dos cuentas independientes que no
se pueden correlacionar — aislamiento por sobre conveniencia (
standards/data.md§2b). - Invitaciones con tokens de un solo uso que expiran, conservadas tras aceptarse como evidencia de quién dejó entrar a quién.
- Un registro global de permisos
{module}.{resource}.{action}, generado desde las propias declaraciones de ruta para que no pueda separarse de lo que el código verifica. - Roles que agrupan permisos, sembrados como roles de sistema y extensibles por el tenant.
- Las máquinas llevan roles igual que las personas (DEC-D5): una API key o un cliente OAuth es un sujeto con asignaciones de rol, verificado por el mismo camino de código.
- Autenticación: contraseña, magic link y passkey, con social y SSO empresarial en F1b.
- MFA con TOTP y códigos de recuperación de un solo uso, hasheados.
- Sesiones que un usuario puede inspeccionar y revocar por dispositivo.
- OAuth2 en ambas direcciones: como provider, para que una herramienta socia actúe por cuenta del tenant y el sitio del tenant ofrezca “Sign in with Softcrum”; y como client, para que el personal del tenant entre por su propio proveedor de identidad. El tenant elige; ambas pueden correr a la vez.
- Impersonación de soporte, acotada en el tiempo, con razón obligatoria, y visible en el propio rastro de auditoría del tenant.
Lo que NO hace (normativo)
- No es el realm de member. Los members son contactos autenticados y viven en
core(ADR-010). Un token de un realm nunca satisface al otro. - No es una red de identidad pública. “Sign in with Softcrum” sirve a las superficies propias del tenant y a los socios que autorice. Un cliente siempre está acotado a la organización que lo otorgó, y el sujeto de un member está acotado a esa organización también.
- No hay SCIM ni sincronización de directorio en F1. El aprovisionamiento empresarial es un pedido real que llega con clientes empresariales reales; el modelo de membresía está formado para agregarlo sin migración.
- No hay permisos por registro. Los permisos son por acción, no por fila. “Puede editar esta campaña pero no aquella” queda fuera deliberadamente: es donde los modelos de autorización dejan de ser razonables, para nosotros y para quien los configura.
- Sin contraseña para members. Es una decisión de
core(FS-CORE-0009) y se mantiene: sin contraseña de member no hay contraseña de member que se filtre.
Éxito
Modelo comercial
identity no se vende ni se mide. Dos capacidades se gatean por plan en vez de cobrarse: SSO
empresarial, que es la feature estándar de tier enterprise en toda la industria, y los roles
personalizados por el tenant, donde los planes menores reciben los roles de sistema sembrados.
Los asientos no son una dimensión de facturación. La suite cobra contactos accionables y volumen
(ADR-014, ADR-016), y sumar un cargo por asiento castigaría a un tenant por involucrar a más de su
propio equipo — lo contrario de lo que impulsa la adopción.
Fases
Cumplimiento y riesgo
Para los datos de este módulo Softcrum es responsable, no encargado — son nuestros propios usuarios, no los clientes de nuestros clientes (DEC-J1). Por eso es un schema aparte decore
(ADR-022), y significa que nuestra propia política de privacidad rige acá mientras el DPA rige allá.
Tres riesgos dan forma al diseño:
- Escalamiento de privilegios entre realms. Mitigado estructuralmente: realms separados, audiencias de token separadas, un cliente OAuth que declara un realm y nunca puede alcanzar el otro, y un test que afirma que un token de member es rechazado por todo endpoint de consola.
- Fuga de identidad entre tenants. El mismo email en dos organizaciones nunca debe ser
correlacionable. Mitigado por unicidad por tenant, claims
subpor organización, y respuestas de invitación cuya redacción y tiempo no revelan que una dirección se conoce en otra parte. - Una API key filtrada. Mitigada por hasheo en reposo, un prefijo visible que permite
identificar una key filtrada sin revelarla,
last_used_atpara detección, y rotación sin caída. - Un operador leyendo datos de clientes sin ser detectado. Mitigado haciendo imposible la impersonación sin razón y ventana de tiempo, y exponiéndola en el propio rastro del tenant — que es quien tiene el incentivo de notarla.
Dependencias
Better Auth para ambos realms (ADR-010) — el único vendor de este módulo, y aquel cuyo costo de reemplazo pesa explícitamente la sección de alternativas del ADR-022. Upstash para rate limiting y verificación de replay. Resend para magic links e invitaciones.core.audit_log para el rastro.