El inglés es la versión autoritativa: ../../../modules/identity/.
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.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 en0002desde 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
Un token de un realm nunca puede satisfacer al otro. Eso es estructural, no una verificación.
OAuth en ambas direcciones
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.