Skip to main content
La autenticación es la parte de Iru que debe ser más difícil de engañar. A continuación se explican los fundamentos criptográficos: cómo demuestran los usuarios quiénes son sin un secreto que se pueda compartir, cómo se firman y protegen las solicitudes frente a la reproducción, y cómo la confianza que Iru extiende a tus aplicaciones es verificable y rota de forma segura.

​
Inicio de sesión resistente al phishing

Iru se basa en passkeys (WebAuthn/FIDO2) y credenciales vinculadas al dispositivo. No hay ninguna contraseña que robar mediante phishing, reutilizar o filtrar.

Vinculada al origen real

Una passkey está limitada criptográficamente al origen exacto de Iru. Una credencial emitida para Iru simplemente no producirá una firma válida en un dominio de phishing de apariencia similar.

Sin secretos en el servidor

Iru solo almacena la clave pública, la procedencia del autenticador (AAGUID) y un contador de firmas. La clave privada nunca sale del dispositivo del usuario, por lo que no hay nada en el servidor que robar.

Passkeys reales, con procedencia

El inicio de sesión requiere credenciales detectables (residentes) y captura la atestación del autenticador durante la inscripción, de modo que Iru conoce el tipo de autenticador que se está usando.

Claves de dispositivo vinculadas al hardware

La aplicación Iru Access guarda sus claves en el hardware seguro del dispositivo (el Secure Enclave en Apple, el TPM en Windows) y demuestra su posesión en cada solicitud con una firma por credencial.
La custodia de claves en Secure Enclave / TPM es una propiedad de la aplicación Iru Access en el dispositivo; el servidor verifica la firma de clave pública vinculada al dispositivo en cada llamada.

​
Demostrar que el dispositivo es auténtico

Además de demostrar quién inicia sesión, Iru puede verificar en qué dispositivo lo hace. Apple DeviceCheck valida que una solicitud procede de un dispositivo Apple auténtico y no manipulado, y la comprobación es de cierre en caso de fallo (fail-closed). Omitirla requiere una configuración deliberada. En Windows, las señales del TPM que informa Iru Access alimentan las decisiones sobre el estado de confianza del dispositivo. Consulta Device trust.

​
Cada solicitud se firma y se protege frente a la reproducción

Las solicitudes de la aplicación Iru Access y de las integraciones no se autentican solo con un token de portador. Se firman y se vinculan de forma que una solicitud capturada no se pueda reutilizar. Además, la aplicación Iru Access fija el certificado TLS del servicio con el que se comunica (un control del lado del agente), por lo que no confiará en un proxy que intercepte el tráfico.

​
Confianza de SSO verificable, con rotación de claves segura

Cuando Iru actúa como tu proveedor de identidad, las declaraciones que envía a tus aplicaciones están firmadas para que cada aplicación pueda verificar que proceden realmente de Iru y que no se han alterado.
Las respuestas y aserciones SAML se firman con XML Signature; las aserciones pueden además cifrarse para el proveedor de servicios. Los ID tokens de OIDC se firman con JWS. Iru admite algoritmos modernos (RSA/ECDSA con SHA-256 o superior, cifrado de contenido AES-GCM y encapsulado de claves RSA-OAEP), que se pueden seleccionar por integración para adaptarse a lo que requiere cada servicio.
Iru publica sus claves públicas y metadatos en endpoints estándar: un documento JWKS, OAuth Authorization Server Metadata (RFC 8414) y OpenID Connect Discovery. Los relying parties configuran y actualizan las claves automáticamente.
Las claves de firma rotan cada 30 días con un solapamiento de 24 horas: una nueva clave toma el relevo mientras la anterior sigue verificando los tokens en curso y, después, caduca en lugar de eliminarse. Los tipos de clave incluyen ECDSA P-256/384/521 y RSA-2048. Esto limita el alcance del impacto de cualquier clave concreta sin interrumpir tus aplicaciones.

​
Cifrado y sesiones

  • En tránsito: todo el tráfico está protegido con TLS; las cookies de sesión son Secure, HttpOnly y SameSite.
  • En reposo: los campos sensibles se cifran con AES-256-GCM mediante una clave proporcionada en tiempo de ejecución desde un almacén de secretos gestionado.
  • Sesiones: las sesiones de inicio de sesión son de corta duración con una ventana de inactividad deslizante; los flujos de mayor duración usan tokens de actualización rotativos con desafíos de código de un solo uso (PKCE S256) y detección de reproducción. Las sesiones se pueden revocar globalmente, por usuario o por autenticador, de modo que un dispositivo perdido o una cuenta comprometida se pueden bloquear de inmediato. Consulta Credenciales y sesiones.

​
Próximos pasos

Arquitectura de la plataforma

Los servicios, las regiones y la infraestructura que hay detrás.

Aislamiento multitenant

Cómo se mantienen separados y auditables los datos de cada tenant.

Autenticadores

Las passkeys y la aplicación Iru Access que los usuarios usan a diario.

Aplicaciones SAML y OIDC

Configura la firma y el cifrado que recibe una aplicación concreta.