> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Arquitectura de autenticación

> Cómo hace Iru que el inicio de sesión sea resistente al phishing, firma y protege frente a la reproducción cada solicitud, y establece una confianza de SSO verificable con claves rotativas.

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.

<CardGroup cols={2}>
  <Card title="Vinculada al origen real" icon="link">
    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.
  </Card>

  <Card title="Sin secretos en el servidor" icon="user-shield">
    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.
  </Card>

  <Card title="Passkeys reales, con procedencia" icon="fingerprint">
    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.
  </Card>

  <Card title="Claves de dispositivo vinculadas al hardware" icon="microchip">
    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.
  </Card>
</CardGroup>

<Note>
  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.
</Note>

## 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](/es/identity/authentication/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.

| Mecanismo | Estándar | Qué hace |
| - | - | - |
| **HTTP Message Signatures** | RFC 9421 | Firma el método, la ruta, la autoridad y los componentes clave de la solicitud, de modo que cualquier manipulación en tránsito invalida la solicitud. Esquemas: `ed25519`, `ecdsa-p256-sha256`, `rsa-v1_5-sha256`. |
| **Content-Digest** | RFC 9530 | Un resumen SHA-256/512 vincula la firma al cuerpo exacto de la solicitud. |
| **Pruebas de un solo uso y con límite de tiempo** | - | Las firmas incluyen una ventana `created`/`expires` (máx. \~10 min, ≤5 s de desfase de reloj) y un **nonce almacenado con una restricción de unicidad**. Un nonce reproducido se rechaza. |
| **DPoP** | RFC 9449 | Tokens restringidos al emisor y con prueba de posesión, vinculados a una clave en poder del cliente (con vinculación `htm`/`htu`/`ath` y JTI por prueba). Un token de portador robado es inútil sin la clave privada. |

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.

<AccordionGroup>
  <Accordion title="SSO firmado (y, opcionalmente, cifrado)" icon="file-signature">
    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.
  </Accordion>

  <Accordion title="Descubrimiento basado en estándares" icon="compass">
    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.
  </Accordion>

  <Accordion title="Rotación de claves sin tiempo de inactividad" icon="arrows-rotate">
    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.
  </Accordion>
</AccordionGroup>

## 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](/es/identity/security/credentials-and-sessions).

## Próximos pasos

<CardGroup cols={2}>
  <Card title="Arquitectura de la plataforma" icon="server" href="/es/identity/security/platform-architecture">
    Los servicios, las regiones y la infraestructura que hay detrás.
  </Card>

  <Card title="Aislamiento multitenant" icon="database" href="/es/identity/security/multi-tenant-isolation">
    Cómo se mantienen separados y auditables los datos de cada tenant.
  </Card>

  <Card title="Autenticadores" icon="key" href="/es/identity/authentication/authenticators">
    Las passkeys y la aplicación Iru Access que los usuarios usan a diario.
  </Card>

  <Card title="Aplicaciones SAML y OIDC" icon="file-signature" href="/es/identity/applications/saml-applications">
    Configura la firma y el cifrado que recibe una aplicación concreta.
  </Card>
</CardGroup>