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

# Aplicaciones OIDC

> Configura una aplicación OIDC en Iru Identity: credenciales de cliente y rotación, URI de redirección, ámbitos, asignación de claims, claves de firma y duración de la sesión.

Una **aplicación OIDC** permite a los usuarios iniciar sesión en un servicio que admite OpenID
Connect, con Iru actuando como proveedor de identidad. Iru emite para el servicio un
**client ID** y un **client secret**, envía un **token de ID** después del inicio de sesión y
asigna los atributos del perfil de tus usuarios a los **claims** de ese token.

Usa estas secciones para configurar una aplicación OIDC personalizada o una que hayas
[desvinculado de una plantilla](/es/identity/applications/application-templates).
Editas la configuración en un **borrador** y luego la estableces como versión actual; consulta
[Descripción general de las aplicaciones](/es/identity/applications/applications-overview) para conocer el
modelo de versiones.

## Paso 1: Guardar las credenciales del cliente

Cuando creas una aplicación OIDC, Iru genera un **client ID** y un **client
secret**. El secreto se muestra **solo una vez**, así que copia ambos en un lugar seguro
antes de cerrar el cuadro de diálogo.

<Warning>
  El client secret no se vuelve a mostrar después de su creación. Si lo pierdes, rota
  el secreto para generar uno nuevo.
</Warning>

Los **Protocol details** de la aplicación también enumeran los endpoints que necesita el servicio para comunicarse
con Iru:

| Dato | Qué es |
| - | - |
| **Client ID** | El identificador público de la aplicación. |
| **Well-Known URL** | El documento de detección de OpenID; muchos servicios configuran todo a partir de esta única URL. |
| **Token Endpoint** | Donde el servicio intercambia un código de autorización por tokens. |
| **User Info Endpoint** | Donde el servicio lee los claims del perfil del usuario que ha iniciado sesión. |

## Paso 2: Establecer los URI de redirección

En el **borrador** de la aplicación, en la configuración de OIDC, agrega los URI a los que Iru puede
redirigir:

<Steps>
  <Step title="URI de redirección de inicio de sesión permitidos">
    Adonde Iru devuelve al usuario después de un inicio de sesión correcto. Agrega todas las URL que
    use el servicio.
  </Step>

  <Step title="URI de redirección de cierre de sesión permitidos">
    Adonde Iru devuelve al usuario después de cerrar sesión.
  </Step>
</Steps>

<Note>
  Los URI de redirección deben coincidir exactamente. Existe una opción para permitir comodines en
  los URI de redirección; déjala desactivada a menos que el servicio lo requiera específicamente, ya que
  la coincidencia exacta es más segura.
</Note>

## Paso 3: Elegir los ámbitos

Los **ámbitos** (scopes) controlan qué categorías de claims puede solicitar el servicio. Iru
ofrece los ámbitos estándar de OpenID Connect:

| Ámbito | Concede acceso a |
| - | - |
| **OpenID** (`openid`) | Necesario para OpenID Connect; siempre se incluye. |
| **Profile** (`profile`) | Claims básicos del perfil. |
| **Correo electrónico** (`email`) | El correo electrónico del usuario. |
| **Address** (`address`) | La dirección del usuario. |
| **Phone** (`phone`) | El número de teléfono del usuario. |
| **Offline access** (`offline_access`) | Un token de actualización, para que el servicio pueda mantener la sesión iniciada sin volver a solicitarla. |

<Tip>
  `openid` siempre está presente y no se puede quitar. Habilita solo los ámbitos
  adicionales que el servicio realmente necesite.
</Tip>

## Paso 4: Asignar el sujeto y los claims

Abre la **asignación** de la aplicación. La asignación tiene un **Asunto** más los
**claims** adicionales.

### Sujeto

El sujeto es el identificador principal del usuario que ha iniciado sesión, enviado como el
claim `sub`. Para una aplicación OIDC, el sujeto predeterminado se asigna a partir del
`user.id` del usuario. Puedes cambiar el valor del que se obtiene y asociarlo a un ámbito.

### Claims

Agrega los claims adicionales que el servicio espere en el token de ID. Para cada uno estableces:

* Un **Name:** el nombre del claim.
* Un **valor:** el atributo del perfil o la expresión de la que se obtiene.
* Un **ámbito:** el ámbito al que pertenece el claim.
* Si está **habilitado**.

Una **vista previa** en vivo muestra el token que se generará, para que puedas confirmar los
claims antes de publicar.

<Warning>
  Algunos nombres de claims están reservados por el estándar OpenID Connect y no se pueden
  usar como claims personalizados: `iss`, `aud`, `exp`, `nbf`, `iat` y `jti`.
</Warning>

## Paso 5: Rotar el client secret

El client secret se puede rotar sin volver a crear la aplicación, desde
**Protocol details → Client secrets** de la aplicación.

<AccordionGroup>
  <Accordion title="Rotar" icon="rotate">
    **Rotate** emite un nuevo client secret mientras el anterior sigue funcionando durante
    **24 horas**, para que puedas actualizar el servicio antes de que el secreto antiguo deje de funcionar. Durante
    ese periodo, el secreto anterior aparece con la insignia **Expires Soon**; un
    secreto recién emitido tiene una larga duración.
  </Accordion>

  <Accordion title="Invalidar" icon="ban">
    **Invalidate** anula el secreto actual de inmediato, sin periodo de gracia. Úsalo
    si un secreto puede haber quedado expuesto y luego actualiza el servicio de inmediato.
  </Accordion>
</AccordionGroup>

<Note>
  Iru administra las claves de firma que usa para firmar los tokens de ID y las publica en los
  endpoints de detección y de claves, para que los servicios validen los tokens automáticamente; no
  hay nada que rotar manualmente.
</Note>

## Paso 6: Publicar, asignar y activar

<Steps>
  <Step title="Establecer el borrador como actual">
    Publica tu borrador para que se convierta en la configuración en vivo.
  </Step>

  <Step title="Asignar acceso">
    Asigna los grupos que deben tener la aplicación. Consulta
    [Asignar acceso](/es/identity/applications/assigning-access).
  </Step>

  <Step title="Activar">
    Activa la aplicación para que los usuarios asignados puedan iniciar sesión.
  </Step>

  <Step title="Probar el inicio de sesión">
    Inicia sesión como usuario de prueba desde el panel de aplicaciones para confirmar la experiencia.
  </Step>
</Steps>

## Flujo de autenticación

Una aplicación OIDC inicia la sesión de los usuarios con el **flujo de código de autorización**:

<Steps>
  <Step title="Redirigir a Iru">
    La aplicación envía al usuario a Iru para iniciar sesión.
  </Step>

  <Step title="Autenticar y evaluar la política">
    Iru autentica al usuario y evalúa la
    [política de autenticación](/es/identity/authentication/authentication-policies) de la aplicación.
  </Step>

  <Step title="Devolver un código de autorización">
    Iru redirige de vuelta al **URI de redirección** de la aplicación con un **código**
    de autorización de corta duración.
  </Step>

  <Step title="Intercambiar el código por tokens">
    La aplicación intercambia el código en el **endpoint de token** de Iru por un **token de ID** (quién
    es el usuario) y un **token de acceso**.
  </Step>

  <Step title="Leer los claims (y mantener la sesión iniciada)">
    La aplicación puede llamar al **endpoint de información del usuario** con el token de acceso para leer
    los claims del perfil y (si habilitaste `offline_access`) usar un **token de actualización**
    para mantener la sesión iniciada.
  </Step>
</Steps>

La mayoría de las bibliotecas configuran todo este flujo a partir de la **Well-Known URL** de
**Protocol details**.

## Próximos pasos

<CardGroup cols={2}>
  <Card title="Asignar acceso" icon="user-check" href="/es/identity/applications/assigning-access">
    Concede la aplicación a usuarios y grupos.
  </Card>

  <Card title="Aprovisionamiento" icon="arrows-rotate" href="/es/identity/applications/provisioning">
    Crea y quita cuentas en la aplicación automáticamente a medida que cambia el acceso.
  </Card>

  <Card title="Políticas de autenticación" icon="shield-halved" href="/es/identity/authentication/authentication-policies">
    Decide quién puede iniciar sesión y qué debe demostrar.
  </Card>

  <Card title="Descripción general de las aplicaciones" icon="grip" href="/es/identity/applications/applications-overview">
    Revisa los protocolos y el modelo de versiones de borrador a actual.
  </Card>
</CardGroup>