> ## Documentation Index > Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt > Use this file to discover all available pages before exploring further. # Módulo — identity (IDN) > El realm organizacional y el plano de control de acceso de la plataforma. Schema identity. Establecido por ADR-022. No depende de nada. Ningún otro módulo lee sus tablas: reciben un contexto de autorización ya resuelto desde la capa de API. > **El inglés es la versión autoritativa**: [`../../../modules/identity/`](/modules/identity/overview). | Documento | Propósito | | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | [`prd.md`](/es/modules/identity/prd) | Qué es el módulo, para quién, qué NO hace, éxito, fases | | [`spec.md`](/es/modules/identity/spec) | La forma técnica viva: entidades, invariantes, eventos, endpoints | | [`features/`](https://github.com/softcrumlabs/softcrum-suite/tree/master/docs/internal/es/modules/identity/features) | Los feature specs — las unidades de entrega | ## Hoja de ruta Nueve entregas. Seis componen F1a, porque nada en la plataforma se puede construir sin un llamador autenticado y un permiso que verificar. | FS | Feature | Fase | Depende de | Estado | | --------------------------------------------------------------------------------- | --------------------------------------------------- | ---- | ---------- | ------- | | [FS-IDN-0001](/es/modules/identity/features/fs-idn-0001-organizations-and-users) | Organizaciones, usuarios, membresías e invitaciones | F1a | — | `draft` | | [FS-IDN-0002](/es/modules/identity/features/fs-idn-0002-permission-registry-rbac) | Registro de permisos y RBAC | F1a | 0001 | `draft` | | [FS-IDN-0003](/es/modules/identity/features/fs-idn-0003-authentication-methods) | Métodos de autenticación | F1a | 0001 | `draft` | | [FS-IDN-0004](/es/modules/identity/features/fs-idn-0004-sessions-and-devices) | Sesiones y gestión de dispositivos | F1a | 0003 | `draft` | | [FS-IDN-0005](/es/modules/identity/features/fs-idn-0005-mfa) | Autenticación multifactor | F1a | 0003 | `draft` | | [FS-IDN-0006](/es/modules/identity/features/fs-idn-0006-api-keys) | Credenciales de máquina — API keys | F1a | 0002 | `draft` | | [FS-IDN-0007](/es/modules/identity/features/fs-idn-0007-oauth-provider) | OAuth2 provider — Sign in with Softcrum | F1b | 0002, 0006 | `draft` | | [FS-IDN-0008](/es/modules/identity/features/fs-idn-0008-social-sso) | Login social y SSO empresarial | F1b | 0003 | `draft` | | [FS-IDN-0009](/es/modules/identity/features/fs-idn-0009-impersonation) | Impersonación de soporte | F1b | 0002, 0004 | `draft` | ## El corte, explicado * **El registro de permisos antes que todo lo que lo usa** (`0002`). Es un artefacto generado: las rutas declaran permisos, el registro se construye desde esas declaraciones, y CI falla ante divergencia. Los endpoints de todos los demás módulos dependen de que exista. * **Autenticación y sesiones van separadas** (`0003`, `0004`). Probar quién eres y mantenerte probado son problemas distintos: uno es un intercambio de credenciales, el otro es revocación, inventario de dispositivos y expiración. Fallan distinto. * **API keys en F1a, OAuth2 en F1b** (`0006`, `0007`). Una integración servidor-a-servidor necesita una key el primer día. Un provider OAuth2 con pantalla de consentimiento es superficie de producto y puede seguir — pero el modelo de scopes que renderiza se define en `0002` desde el inicio. * **La impersonación al final** (`0009`), porque es la capacidad más peligrosa de la plataforma y no debería existir antes que el rastro de auditoría que la limita. ## Los dos realms | | `identity` (organizacional) | `core` (member) | | ---------------- | ------------------------------------------- | ---------------------------------------------------------------------- | | Quién | Personal del tenant, operadores de Softcrum | Los clientes finales del tenant | | Nuestro rol | **Responsable** | **Encargado** | | Credenciales | contraseña, magic link, passkey, SSO, MFA | OTP, magic link, token exchange | | El token alcanza | Consola, Management API, Ops | Solo endpoints Runtime de member | | Unicidad | por organización | por tenant | | Spec | este módulo | [FS-CORE-0009](/es/modules/core/features/fs-core-0009-member-identity) | Un token de un realm **nunca** puede satisfacer al otro. Eso es estructural, no una verificación. ## OAuth en ambas direcciones | Dirección | Softcrum es | Spec | Qué habilita | | --------- | --------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Saliente | el **provider** | [FS-IDN-0007](/es/modules/identity/features/fs-idn-0007-oauth-provider) | Una herramienta socia actúa por cuenta del tenant · el sitio del tenant ofrece "Sign in with Softcrum" a sus propios clientes | | Entrante | el **client** | [FS-IDN-0008](/es/modules/identity/features/fs-idn-0008-social-sso) | El personal del tenant entra por su propio IdP, o por Google, Microsoft o GitHub | Ninguna es el default. Un tenant puede correr ambas a la vez — personal hacia adentro por su IdP corporativo, clientes hacia afuera por nuestro provider.