Producto
Un runtime de identidad en Go, una consola para operarlo y un SDK para integrarlo. Diseñado como la capa de identidad del ecosistema 4US y de las aplicaciones de tu organización.
auth4us-identity
Binario Go que sirve discovery OpenID Connect, los endpoints OAuth/OIDC, las APIs de administración, SCIM y los callbacks de federación.
servemigrateworkermigrate-legacyTanStack Start · React 19
La interfaz del operador: escritorio, directorio, aplicaciones, confianza, actividad y cuenta. Hace de proxy hacia el runtime para /api, /connect, /.well-known, /health y /scim.
EscritorioDirectorioAplicacionesConfianza@auth4us/*
Cuatro paquetes TypeScript para integrar productos: core headless, guardas de React, interfaz opcional y temas. Más create-auth4us para empezar.
corereactui-reactthemesEl navegador habla con la consola o con tu aplicación; la identidad vive en el runtime, sobre PostgreSQL y Redis. La sesión de la consola y los tokens de tus productos son canales distintos.
Los productos usan tokens OIDC emitidos por /connect/token; no usan la cookie de la consola.
/health/live y /health/ready: Postgres, Redis, llaves y versión del esquema.AUTH4US_EMBEDDED_WORKER=false.La misma disciplina de estados que el producto: verificado, código completo, requiere configuración o parcial.
| 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 | — |
Una demostración con datos sintéticos: tus flujos, tus métodos de entrada y tu modelo de tenants.