> ## 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.

# Credenciales y sesiones

> Cómo protege Iru Identity las credenciales con las que inician sesión los usuarios y las sesiones que mantienen, y cómo finalizar el acceso de inmediato cuando lo necesites.

Detrás de cada usuario que accede a una aplicación a través de Iru hay dos cosas: la
**credencial** que usó para demostrar quién es y la **sesión** que lo mantiene
con la sesión iniciada después. Así es como Iru protege ambas, y cómo puedes cortar el acceso a alguien
cuando lo necesites.

## Cómo se protegen las credenciales

Los usuarios demuestran quiénes son con **autenticadores**, y una **passkey** es el
principal. Las passkeys están diseñadas para resistir el phishing, que es la forma más habitual
de robar credenciales.

<CardGroup cols={2}>
  <Card title="El secreto nunca sale del usuario" icon="fingerprint">
    Una passkey mantiene el secreto que demuestra la identidad vinculado al dispositivo del usuario.
    Al iniciar sesión, se demuestra que se posee sin transmitir nunca el propio secreto,
    por lo que no hay nada reutilizable que un atacante pueda capturar.
  </Card>

  <Card title="Vinculada a Iru" icon="link">
    Una passkey solo funciona cuando el usuario está iniciando sesión realmente en Iru. Una
    página de phishing de apariencia similar no puede activarla, porque la passkey está vinculada
    al inicio de sesión real de Iru y no responderá a un impostor.
  </Card>

  <Card title="Protegida en reposo" icon="lock">
    Lo que Iru conserva para verificar un autenticador está protegido mientras está
    almacenado, y nunca es suficiente por sí solo para suplantar al usuario.
  </Card>

  <Card title="Gestionadas por usuarios y administradores" icon="user-gear">
    Los usuarios gestionan sus propios autenticadores en autoservicio. Si alguien pierde
    el acceso a los suyos, un administrador puede restablecerlos para que el usuario pueda registrar
    uno nuevo. Consulta [Usuarios](/es/identity/directory/users).
  </Card>
</CardGroup>

<Info>
  Qué autenticadores pueden registrar los usuarios, y cuáles aceptará una política
  para una aplicación determinada, depende de ti. Consulta
  [Autenticadores](/es/identity/authentication/authenticators) y
  [Políticas de autenticación](/es/identity/authentication/authentication-policies).
</Info>

## Qué recibe una aplicación (y qué no ve nunca)

Cuando un usuario accede a una aplicación a través de Iru, la aplicación sabe quién es sin
saber nunca cómo lo demostró. Esta separación es lo que impide que una sola credencial
robada se propague por tus aplicaciones.

<CardGroup cols={2}>
  <Card title="La aplicación recibe" icon="circle-check">
    Una declaración firmada que confirma quién es el usuario, además de los datos de perfil
    que elegiste asignar al inicio de sesión de esa aplicación. Como la declaración está firmada,
    la aplicación puede verificar que procede realmente de Iru y que no se ha manipulado.
  </Card>

  <Card title="La aplicación nunca recibe" icon="circle-xmark">
    La passkey del usuario ni ningún otro secreto de autenticador. Las aplicaciones nunca tienen los
    medios para demostrar la identidad del usuario, por lo que una brecha en una aplicación no se puede
    reproducir contra Iru ni contra tus otras aplicaciones.
  </Card>
</CardGroup>

<Note>
  Tú decides qué atributos de perfil se comparten con cada aplicación, de modo que una
  aplicación solo ve los datos que necesita para identificar al usuario. Consulta
  [Asignar acceso](/es/identity/applications/assigning-access).
</Note>

## Cómo se protegen las sesiones

Después de un inicio de sesión correcto, Iru establece una sesión para que no se pida al usuario
que vuelva a demostrar su identidad en cada clic. Las sesiones están protegidas para que no se puedan
tomar prestadas ni prolongar indefinidamente.

<AccordionGroup>
  <Accordion title="Las sesiones caducan" icon="clock">
    Una sesión no dura para siempre: finaliza tras un periodo de inactividad y
    también al alcanzar una antigüedad máxima, tras lo cual el usuario inicia sesión y la política
    que la rige se evalúa de nuevo. La duración de la sesión que se presenta a una aplicación conectada se puede
    configurar por [aplicación SAML](/es/identity/applications/saml-applications) y
    por [rol de aplicación](/es/identity/applications/roles-and-bundles).
  </Accordion>

  <Accordion title="Cada inicio de sesión en una aplicación se comprueba con la política" icon="shield-halved">
    Iniciar sesión en una aplicación conectada pasa por la política de autenticación de esa aplicación,
    por lo que una aplicación sensible puede exigir un dispositivo de confianza incluso cuando el usuario
    ya ha iniciado sesión en Iru. (En cualquier caso, se requiere una passkey o Iru Access para cada
    inicio de sesión). Consulta
    [Políticas de autenticación](/es/identity/authentication/authentication-policies)
    y [Device trust](/es/identity/authentication/device-trust).
  </Accordion>

  <Accordion title="Las sesiones se pueden finalizar cuando sea necesario" icon="right-from-bracket">
    Las sesiones activas de un usuario se pueden finalizar, lo que lo obliga a volver a iniciar sesión
    antes de poder continuar. Así es como cortas el acceso incluso cuando alguien
    ya ha iniciado sesión.
  </Accordion>
</AccordionGroup>

## Finalizar el acceso de inmediato

Cuando el acceso debe detenerse, no tienes que esperar a que caduque una sesión. Elige
la acción que se ajuste a la situación; cada una se registra en el
[registro de actividad](/es/identity/administration/activity-log).

| Acción | Qué hace | ¿Reversible? |
| - | - | - |
| **Finalizar sesiones** | Finaliza las sesiones activas del usuario para que deba volver a iniciar sesión. | Sí; puede volver a iniciar sesión si sigue activo. |
| **Suspender al usuario** | Bloquea todos los inicios de sesión y conserva el registro y el historial. Se corta el acceso existente y se rechazan los nuevos inicios de sesión. | Sí; al restablecerlo, recupera su estado anterior. |
| **Retirar el acceso a una aplicación** | Revoca una asignación; en las aplicaciones que admiten aprovisionamiento, también se puede eliminar la cuenta en ellas. | Sí; vuelve a asignarla para restaurarlo. |
| **Eliminar al usuario** | Borra por completo el registro del directorio. | No; no se puede deshacer. |

<Note>
  **Finalizar una sesión dentro de una aplicación conectada depende de la aplicación.** Finalizar las sesiones
  y suspender a un usuario detiene de inmediato los nuevos inicios de sesión **a través de Iru**. Si la
  sesión *existente* de un usuario dentro de una aplicación conectada también finaliza depende de esa aplicación
  y de su protocolo:

  * Las aplicaciones que consultan a Iru en cada acceso dejan de permitir la entrada al usuario en la siguiente
    comprobación.
  * En las aplicaciones aprovisionadas con [SCIM](/es/identity/applications/provisioning),
    suspender o desasignar al usuario envía a la aplicación una **desactivación** (el indicador
    `active` de la cuenta se establece en `false`) o una **eliminación**. Que eso
    finalice inmediatamente las sesiones activas de la aplicación depende de cómo gestione la aplicación
    esa señal.
  * Algunas aplicaciones mantienen una sesión existente hasta que caduca, a menos que admitan la revocación
    de sesiones o el cierre de sesión único.

  Para cortar el acceso a alguien de la forma más completa posible, **suspende al usuario** y **finaliza
  sus sesiones**, y confía en el desaprovisionamiento de cada aplicación para eliminar el acceso
  en los sistemas dependientes.
</Note>

<Warning>
  Suspender a un usuario es la acción individual más segura para cortarle el acceso en todas partes a
  la vez: detiene los nuevos inicios de sesión y el acceso existente sigue bloqueado hasta que lo
  restablezcas. Eliminar a un usuario es permanente; suspéndelo si existe alguna
  posibilidad de que regrese o necesitas su historial. Consulta
  [Usuarios](/es/identity/directory/users).
</Warning>

<Tip>
  Si sospechas que lo que está comprometido es una credencial y no el usuario, restablece los
  autenticadores del usuario y finaliza sus sesiones. Conserva su cuenta, pero
  debe registrar un autenticador nuevo antes de volver a iniciar sesión.
</Tip>

## Cómo se contiene una credencial comprometida

Las piezas anteriores funcionan juntas para que una credencial robada no provoque un efecto en cadena:

1. Las passkeys no dan a los atacantes nada reutilizable que robar mediante phishing.
2. Las aplicaciones nunca reciben los medios para demostrar la identidad, por lo que una aplicación comprometida no se puede
   reproducir contra Iru.
3. Si algo sale mal, suspender al usuario y finalizar sus sesiones corta
   el acceso de inmediato, y cada paso queda registrado para su revisión.

## Próximos pasos

<CardGroup cols={2}>
  <Card title="Seguridad y privacidad" icon="shield-halved" href="/es/identity/security/security-and-privacy">
    El planteamiento completo de seguridad y privacidad, expresado como garantías sencillas.
  </Card>

  <Card title="Autenticadores" icon="fingerprint" href="/es/identity/authentication/authenticators">
    Elige qué autenticadores registran y usan los usuarios.
  </Card>

  <Card title="La experiencia de inicio de sesión" icon="arrow-right-to-bracket" href="/es/identity/authentication/sign-in-experience">
    Lo que ven los usuarios cuando inician sesión a través de Iru.
  </Card>

  <Card title="Usuarios" icon="user" href="/es/identity/directory/users">
    Suspende, restablece, reinicia autenticadores y gestiona los usuarios de tu
    directorio.
  </Card>
</CardGroup>