Seguridad
Controles concretos, nombrados y verificables.
Esta página describe controles de arquitectura del producto y la evidencia que los respalda. No es una certificación ni la sustituye.
- Descubrir
- Autorizar
- Probar
- Verificar
- Consentir
- Emitir
- Sesión
- Revocar
Emitir
Tokens firmados que se pueden verificar, y llaves que rotan sin cortes.
Las llaves de firma viven en un archivo cifrado por defecto, o en Azure Key Vault o AWS KMS cuando se configuran.
ES256 sobre P-256. JWKS publica su parte pública para que cualquier cliente verifique.
La nueva llave pública aparece en /.well-known/jwks.json antes de firmar nada.
La firma cambia a la nueva llave. Prepublicar y activar exigen permiso keys.rotate y step-up.
Los tokens firmados con la llave anterior siguen verificando mientras dure la superposición.
Termina el periodo y la llave anterior deja de publicarse. Ninguna llave privada aparece jamás en el sitio ni en el JWKS.
Riesgo determinista, no adivinanzas.
Reglas explícitas con puntos fijos y bandas de decisión. Mismas señales, misma decisión, siempre. Sin modelos opacos.
| Señal | Regla | Puntos |
|---|---|---|
token_reuse | Reutilización de un token | — |
impossible_travel | Viaje imposible | — |
login_velocity | ≥ 20 intentos fallidos en la ventana | — |
login_velocity | ≥ 8 intentos fallidos en la ventana | — |
user_failures | ≥ 5 fallos de la misma cuenta | — |
ip_velocity | ≥ 6 IPs distintas en la ventana | — |
new_device | Dispositivo nuevo | — |
recovery_abuse | ≥ 3 intentos de recuperación | — |
mfa_failures | ≥ 4 fallos de MFA | — |
| Puntaje | 0 | |
allow< 15review15–29step_up30–59block60–99revoke≥ 100
Revocar
Cerrar a tiempo, aislar siempre y dejar rastro.
Un token de un tenant no cruza a otro. Una sesión cerrada avisa a las aplicaciones. Y cada acción sensible queda en la auditoría.
En modo compartido, el tenant sale del client_id persistido o de un dominio verificado.
Verificado multi-nodoSi un identificador existe en dos tenants, la resolución falla cerrada.
Verificado en CI de integraciónLa cabecera X-Tenant-ID no elige tenant: se descarta.
Verificado en CI de integración
Auditoría con la taxonomía real
LOGIN_SUCCEEDEDInicio de sesión con contraseñaPASSWORD_UPGRADEDHash heredado actualizado a Argon2idPASSWORD_CHANGE_SUCCEEDEDCambio de contraseña con step-upCLIENT_SECRET_ROTATEDRotación del secreto de un clienteCONFIGURATION_IMPORTEDImportación de configuración validadaLOGIN_FAILEDInicio fallido, clasificado por el motor de riesgoREFRESH_REUSERefresh reutilizado: familia revocadaBACKCHANNEL_LOGOUTLogout token enviado a una aplicación
En producción, AUTH4US se niega a arrancar con:
- Emisor con http en lugar de https
- Sin DATABASE_URL
- Sin Redis
- Secreto HMAC de desarrollo o corto
- Llave de cifrado (KEK) débil
- Proveedor de firma incompleto
Contraseñas con Argon2id y memoria de lo que pasó.
Política por tenant con longitud mínima e historial. Bloqueo temporal con contador compartido entre nodos.
- Algoritmo
- Argon2id, 19 MiB, 2 iteraciones, sal de 16 bytes
- Política por defecto
- Mínimo 12 caracteres, mayúscula, minúscula y dígito; historial de 24
- Bloqueo
- 5 fallos en 1 minuto, contador en Redis compartido
- Hashes heredados
- Se actualizan a Argon2id en el siguiente inicio
- Cambio o restablecimiento
- Rota el sello y revoca sesiones y grants
Los secretos no viajan al navegador.
Los clientes públicos usan PKCE. El navegador nunca recibe secreto de cliente, HMAC, KEK ni llave de firma, y el access token vive solo en memoria.
- Nada de secretos en localStorage ni en eventos del SDK: los campos de token, contraseña, verificador y código se descartan.
- create-auth4us se niega a escribir valores con forma de secreto.
- El documento OpenAPI de administración solo existe fuera de producción.
- Las referencias a secretos pueden resolverse desde Azure Key Vault o AWS Secrets Manager.
Cada cambio pasa por la misma batería.
La evidencia de esta página viene de la integración continua del repositorio de AUTH4US.
- Pruebas
- go test, go test -race, pruebas TypeScript
- Análisis estático
- gofmt, go vet, staticcheck
- Vulnerabilidades
- govulncheck y npm audit
- Integración
- PostgreSQL 16 y Redis 7 reales; falla si alguna prueba se omite
- Imagen
- docker build y SBOM SPDX
- Cadena de suministro
- gitleaks, helm lint y helm template
- Producción
- Arranques que deben fallar y flujos de token tras reinicio
- Multi-nodo
- Tres runtimes sobre la misma base; workers que reclaman cada mensaje una sola vez
Veámoslo con tus aplicaciones.
Una demostración con datos sintéticos: tus flujos, tus métodos de entrada y tu modelo de tenants.