Recursos
Documentación, estado y vocabulario.
La documentación vive junto al código de AUTH4US. Aquí está el mapa, la matriz de verificación pública y un glosario para quien llega nuevo a la identidad.
- Descubrir
- Autorizar
- Probar
- Verificar
- Consentir
- Emitir
- Sesión
- Revocar
Documentación del producto.
Archivos del repositorio de AUTH4US. Pide acceso a tu contacto de TIGLOBAL si aún no lo tienes.
Manual de usuario e integración
docs/manual.mdOperación de la consola, flujos de autenticación e integración de productos, en español.
Guía de @auth4us/core
docs/sdk/core.mdCliente headless, estados, eventos filtrados y reglas de cliente público.
Guía de @auth4us/react
docs/sdk/react.mdProveedor, hooks, guardas y AuthCallback.
Guía de @auth4us/ui-react
docs/sdk/ui-react.mdComponentes, escenas por método y regla de éxito confirmado.
Guía de @auth4us/themes
docs/sdk/themes.mdPresets, variables CSS y modos.
Federación
docs/federation.mdConexiones OIDC y SAML, y su configuración.
Autoservicio
docs/self-service.mdPerfil, completitud y sesiones propias.
Estado del producto
ESTATUS.mdLibro de estado: qué está hecho y qué requiere configuración.
Matriz de verificación.
Cada afirmación del sitio sale de esta lista, con su estado. Verificado significa probado en el producto o en su integración continua; requiere configuración significa que el código existe y depende de tu despliegue.
| Capacidad | Estado | Alcance |
|---|---|---|
| AUTH4US funciona como proveedor OpenID Connect con descubrimiento estándar y endpoints OAuth 2.0. | Verificado en CI de integración | — |
| Publica /.well-known/openid-configuration y /.well-known/jwks.json para que los clientes descubran endpoints y llaves. | Verificado en CI de integración | — |
| Código de autorización con PKCE para aplicaciones web y móviles, probado en tres nodos sobre la misma base. | Verificado multi-nodo | — |
| PKCE es obligatorio para clientes públicos y solo se acepta el método S256; el método plain está deshabilitado. | Verificado en el producto | — |
| Credenciales de cliente para integraciones servicio a servicio, con el secreto siempre del lado del servidor. | Verificado multi-nodo | — |
| Los tokens de refresco rotan en cada uso. | Verificado multi-nodo | — |
| Si se reutiliza un token de refresco ya consumido, se revoca toda su familia de tokens. | Verificado multi-nodo | — |
| Flujo de código de dispositivo para televisores, CLI y equipos sin teclado cómodo. | Verificado multi-nodo | — |
| No se registran el flujo implícito ni el de contraseña del propietario del recurso. | Verificado en el producto | — |
| El único tipo de respuesta de autorización es code. | Verificado en el producto | — |
| El consentimiento se recuerda por cliente y ámbitos; un ámbito sin consentimiento activo se niega. | Verificado multi-nodo | — |
| Introspección y revocación de tokens con autenticación HTTP Basic del cliente confidencial. | Verificado en CI de integración | — |
| El cierre de sesión solo redirige a una post_logout_redirect_uri registrada de forma exacta. | Verificado multi-nodo | — |
| Al cerrar sesión, AUTH4US envía un logout token firmado (ES256) a las aplicaciones registradas. | Verificado multi-nodo | Se notifica a todo cliente activo con URI de back-channel registrada; si un receptor falla, el cierre local igual se completa. |
| Los tokens se firman con llaves ES256 publicadas en el JWKS. | Verificado en el producto | — |
| Directorio por inquilino: personas, organizaciones, grupos y roles. | Verificado en CI de integración | — |
| Permisos efectivos derivados de roles asignados por membresía; el producto consulta, AUTH4US decide. | Código completo | — |
| Las contraseñas se almacenan con Argon2id. | Verificado en CI de integración | — |
| Política de contraseñas por inquilino con longitud mínima e historial. | Verificado en CI de integración | Los valores de bloqueo de la política no gobiernan hoy el bloqueo de inicio de sesión. |
| Bloqueo temporal tras intentos fallidos, con contador compartido entre nodos vía Redis. | Verificado multi-nodo | Umbral fijo: 5 fallos, ventana de 1 minuto. No es configurable por política en esta versión. |
| Cambiar o restablecer la contraseña invalida las sesiones y revoca los tokens de acceso y refresco de esa persona. | Verificado multi-nodo | — |
| TOTP con alta, confirmación, verificación y desactivación protegida por step-up. | Verificado en CI de integración | — |
| Códigos de recuperación de un solo uso, generados con step-up. | Código completo | Consumir un código de recuperación no eleva hoy la sesión para acciones sensibles. |
| Passkeys con WebAuthn: registro, inicio por usuario, sin contraseña y descubrible. | Código completo | Implementado sobre el estándar WebAuthn. No se ha verificado en vivo con autenticadores físicos. |
| Cada inquilino define su política WebAuthn, incluida la exigencia de llave de hardware y listas AAGUID. | Verificado en CI de integración | — |
| Las acciones sensibles exigen un segundo factor reciente; una sesión solo con contraseña no basta. | Verificado multi-nodo | Factores que hoy elevan la sesión: TOTP o passkey. |
| Un inquilino puede exigir llave de hardware para mutaciones de secretos de cliente, llaves de firma y federación. | Verificado en CI de integración | Cambiar la contraseña no exige llave de hardware. |
| Motor de riesgo determinista basado en reglas explícitas, sin modelos opacos. | Parcial | Hoy la decisión solo clasifica eventos de inicio fallido; no bloquea, no pide step-up ni revoca en tiempo de ejecución. |
| Sesiones compartidas entre nodos, revocables por la persona o por un operador. | Verificado multi-nodo | Duración por defecto: 8 h de inactividad y 24 h absolutas. |
| Toda mutación con cookie de sesión exige la cabecera X-CSRF-Token. | Verificado en el producto | — |
| Cada sesión registra métodos de autenticación (AMR) y nivel de aseguramiento (AAL). | Verificado multi-nodo | — |
| Cada persona ve y revoca sus propias sesiones desde su cuenta. | Código completo | — |
| Si faltan datos obligatorios del perfil, AUTH4US los pide y retoma el flujo con una continuación segura de un solo uso. | Código completo | — |
| Confirmación de correo con ticket de un solo uso que marca la dirección como verificada. | Requiere configuración | El envío real requiere un proveedor de correo configurado. |
| SCIM 2.0 en /scim/v2 para usuarios y grupos, con tokens ligados a un inquilino. | Verificado multi-nodo | PATCH admite add y replace; filtros solo userName/externalId con eq; sin operaciones bulk. |
| Las escrituras SCIM condicionales respetan If-Match. | Código completo | — |
| En modo compartido, el inquilino se resuelve por client_id persistido o dominio verificado. | Verificado multi-nodo | — |
| Si un identificador existe en dos inquilinos, la resolución falla cerrada. | Verificado en CI de integración | — |
| La cabecera X-Tenant-ID no selecciona inquilino. | Verificado en CI de integración | — |
| Federación OIDC con proveedores empresariales, con validación de emisor, audiencia, firma y vigencia. | Requiere configuración | Requiere configurar la conexión y su secreto. Sin verificación en vivo con un IdP externo. |
| Federación SAML con metadatos, inicio y ACS. | Requiere configuración | Requiere certificado, llave y metadatos del IdP. Sin verificación en vivo. |
| Cada aserción SAML se consume una sola vez para impedir su repetición. | Verificado en CI de integración | Requiere SAML configurado en el despliegue. |
| Un dominio verificado puede dirigir el inicio de sesión a la conexión empresarial que corresponde. | Verificado multi-nodo | — |
| El alta automática (JIT) de cuentas federadas ocurre solo si la política del inquilino la habilita. | Requiere configuración | Apagado salvo que el inquilino active jit_enabled. |
| Los claims de usuario prevalecen y los de rol completan los faltantes; los claims reservados se descartan. | Verificado en CI de integración | — |
| Cada redirect_uri debe estar registrada de forma exacta. | Verificado multi-nodo | — |
| CORS por origen exacto registrado: sin comodines, sin http inseguro y sin orígenes de otro cliente. | Código completo | — |
| Rotación de secretos de cliente con permiso, CSRF y step-up. | Verificado multi-nodo | Disponible por API de administración; el secreto anterior sigue válido hasta revocarlo. |
| Clonar un cliente copia redirecciones, URIs de logout y orígenes CORS, nunca secretos ni consentimientos. | Código completo | — |
| Exportación versionada e importación validada de configuración; se rechazan secretos y material de llave. | Código completo | Validar antes de importar. No es infraestructura como código completa. |
| Llaves de firma en archivo PKCS#8 cifrado, proveedor por defecto. | Verificado en el producto | — |
| Adaptador de Azure Key Vault para llaves de firma. | Requiere configuración | Requiere configuración. Sin verificación en vivo. |
| Adaptador de AWS KMS para llaves de firma. | Requiere configuración | Requiere configuración. Sin verificación en vivo. |
| Rotación con prepublicación y solapamiento: los tokens firmados con la llave anterior siguen verificando hasta su retiro. | Verificado en el producto | Verificado con el proveedor de archivo. No hay llave por inquilino. |
| Eventos de auditoría persistidos en PostgreSQL y legibles desde cualquier nodo. | Verificado multi-nodo | — |
| Eventos de seguridad como inicios fallidos y reutilización de refresco, con permiso de lectura dedicado. | Verificado multi-nodo | — |
| El escritorio muestra conteos de personas, organizaciones, sesiones y eventos de auditoría. | Verificado en el producto | Usar solo datos sintéticos de demostración. |
| /health/live y /health/ready; ready revisa Postgres, Redis, llaves y versión del esquema. | Verificado en CI de integración | — |
| En producción el servicio no arranca con emisor HTTP, sin base o Redis, con secretos débiles o proveedor de firma incompleto. | Verificado en CI de integración | — |
| Bandeja de salida en PostgreSQL con FOR UPDATE SKIP LOCKED y workers independientes. | Verificado en CI de integración | Procesar la cola no equivale a entrega externa de correo. |
| Envío de correo mediante Microsoft Graph, SendGrid o SMTP, elegido explícitamente. | Requiere configuración | Requiere proveedor configurado. Sin verificación en vivo. |
| Los secretos pueden resolverse desde referencias a Azure Key Vault o AWS Secrets Manager antes de servir. | Requiere configuración | Requiere configuración. Sin verificación en vivo con bóvedas reales. |
| El documento OpenAPI de administración solo existe fuera de producción. | Código completo | — |
| La sesión de consola usa cookie HttpOnly; los productos usan tokens OIDC. Son canales separados. | Verificado en el producto | — |
| @auth4us/core: cliente TypeScript sin interfaz y sin dependencia de React. | Código completo | Paquete interno del repositorio; aún no publicado en npm. |
| @auth4us/react: proveedor, hooks y puertas de acceso para React. | Código completo | Paquete interno del repositorio; aún no publicado en npm. |
| @auth4us/ui-react: componentes opcionales de entrada con escenas por método, sin WebGL. | Código completo | Paquete interno del repositorio; aún no publicado en npm. |
| @auth4us/themes: siete presets, modos claro, oscuro y sistema, y variables CSS personalizables. | Código completo | — |
| create-auth4us genera configuración pública, proveedor, callback y puerta RequireAuth sin escribir secretos. | Código completo | Asistente interactivo interno; genera código React. |
| El navegador nunca recibe secreto de cliente, HMAC, KEK ni llave de firma. | Código completo | — |
| El access token vive solo en memoria; no se escribe en localStorage ni en eventos. | Código completo | — |
| Diseñado como la capa de identidad del ecosistema 4US. | Información del propietario | Integraciones de ejemplo. No se afirma SSO entre productos 4US en producción. |
| Diseñado y probado para operar con varios nodos sobre una misma base PostgreSQL y Redis. | Verificado multi-nodo | Evidencia de CI; no implica activo-activo geográfico. |
| Chart de Helm con Job de migración y despliegue de tres réplicas por defecto. | Código completo | — |
| Cada cambio pasa pruebas, análisis estático, revisión de vulnerabilidades, SBOM y escaneo de secretos. | Verificado en CI de integración | — |
| Migración de usuarios desde ASP.NET Identity con rehash a Argon2id en el primer inicio. | Requiere configuración | Requiere validar con datos fuente reales. No se importan grants. |
| Perfil de compatibilidad 4us-v1 que conserva rutas y ámbitos usados por clientes 4US existentes. | Código completo | — |
Glosario.
- AAL
- Nivel de garantía de autenticación. AUTH4US usa urn:auth4us:aal1 y aal2.
- AMR
- Métodos con los que se autenticó la sesión: pwd, otp, hwk, fed.
- Back-channel logout
- Aviso firmado de servidor a servidor cuando una sesión termina.
- Consentimiento
- Permiso explícito de la persona para que una aplicación reciba ciertos scopes.
- Device code
- Flujo para dispositivos sin teclado cómodo: se aprueba desde otro navegador.
- Discovery
- Documento /.well-known/openid-configuration con los endpoints del emisor.
- Home realm discovery
- Elegir la conexión empresarial a partir del dominio verificado del usuario.
- JIT
- Alta automática de una cuenta federada; solo si la política del tenant la permite.
- JWKS
- Conjunto de llaves públicas para verificar las firmas de los tokens.
- PKCE
- Prueba de que quien canjea el código es quien lo pidió; AUTH4US exige S256.
- SCIM
- Estándar para que una fuente de identidad cree y actualice cuentas y grupos.
- Sello de seguridad
- Valor que, al rotar, invalida las sesiones emitidas antes.
- Step-up
- Pedir una prueba más fuerte antes de una acción sensible.
- Tenant
- Organización con su propio directorio, políticas y límites.
Veámoslo con tus aplicaciones.
Una demostración con datos sintéticos: tus flujos, tus métodos de entrada y tu modelo de tenants.