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

# Configuración de la integración con Okta

> Conecte Okta a Living Security para obtener datos del ciclo de vida de los usuarios, la autenticación, la MFA y la actividad administrativa.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Recursos relacionados</h2>
    <ul>
      <li>
        <a href="/es/signals/data-sources">Descubra cómo los datos de las integraciones se convierten en señales de Human Risk Management</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Explore las integraciones de Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Abra Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Solicite una demostración de Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Agregue las cuatro direcciones IP de salida de sincronización de Living Security</strong> a la lista de permitidos de{' '}
    {system}. Introduzca cada una como un único host con <code>/32</code> si {system} espera notación CIDR:
    <br />
    <code>52.34.139.153/32</code>, <code>54.69.127.183/32</code>, <code>44.247.133.183/32</code>,{' '}
    <code>52.26.211.56/32</code>
    <br />
    <br />
    El tráfico puede salir desde cualquiera de las cuatro, por lo que permitir solo algunas provoca fallos de
    sincronización intermitentes. Estas cuatro son las mismas en todas las regiones de Living Security. Consulte{' '}
    <a href="/es/integrations/managing/egress-ip-addresses">
      Configuración de las direcciones IP de salida de las Integraciones
    </a>{' '}
    para obtener la lista completa, la política de cambios y la resolución de problemas.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Introduzca las credenciales en Living Security Platform">
    <p>
      Lo realiza la persona que tenga acceso a Living Security: el responsable del programa o el
      administrador del sistema, si se le ha invitado (configuración delegada).
    </p>
    <ol>
      <li>
        Vaya a <strong>Configuración → Integraciones → Catálogo</strong>, busque el icono de{' '}
        <strong>{tile}</strong> y haga clic en <strong>Conectar</strong>.
      </li>
      <li>
        Complete los campos que se indican a continuación y, a continuación, haga clic en <strong>Conectar</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Descripción general

Okta puede aportar actividad normalizada del ciclo de vida de los usuarios, de autenticación, de MFA y administrativa. Entre los ejemplos revisados se incluyen:

* `account.locked` — cuenta bloqueada
* `mfa.factor.activated` — activa factores de MFA adicionales
* `auth.login.failed` — no logra iniciar sesión

Ambos métodos de conexión leen los mismos dos flujos: el directorio de usuarios (`/api/v1/users`) y el registro del sistema (`/api/v1/logs`). Consulte [cómo los datos de las integraciones se convierten en señales](/es/signals/data-sources).

## Elija un método de conexión

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Credencial | Un token de API que usted crea en la Admin Console | Un ID de cliente y una JWK privada que usted genera y registra |
| Configuración | Tres pasos, sin material de claves que generar | Nueve pasos, incluido un par de claves RSA |
| Rol de administrador necesario | Administrador de solo lectura, asignado al propietario del token | Administrador de solo lectura, asignado a la aplicación |
| Vigencia del token | Se desactiva tras 30 días sin uso | No caduca; la rotación del par de claves le corresponde a usted |
| Úselo cuando | Esta es la opción recomendada para la mayoría de las organizaciones | Su política de seguridad prohíbe los tokens de API de larga duración |

Ambos métodos requieren el mismo acceso, por lo que la elección depende del manejo de las credenciales y no de lo que la plataforma puede leer.

***

## Opción A: token de API (SSWS)

*Recomendada.*

### Qué necesita Living Security

| Credencial | Descripción |
| - | - |
| **Clave de API** | Un token de API de Okta. El cuadro de diálogo de conexión denomina este campo **Clave de API** |
| **Subdominio del tenant** | El `<tenant>` en `<tenant>.okta.com`: solo el subdominio, no la URL completa |

### Requisitos previos

* Debe ser **Super Administrator** de Okta para crear un usuario de cuenta de servicio, asignar roles de administrador y crear tokens de API.

<Steps>
  <Step title="Cree un usuario que sea propietario del token">
    Un token de API de Okta tiene los permisos del usuario que lo creó y deja de funcionar si ese usuario se desactiva. Cree una cuenta de servicio dedicada en lugar de usar una cuenta de administrador personal, de modo que la conexión se mantenga ante cambios de personal.

    1. En la Admin Console, vaya a **Directory** → **People**.
    2. Haga clic en **Add person** y cree un usuario como `svc-livingsecurity@yourcompany.com`.
    3. Active la cuenta.
  </Step>

  <Step title="Asigne el rol de administrador de solo lectura">
    La plataforma solo realiza lecturas. Otorgar más que acceso de lectura concede al token permisos que nunca utiliza.

    1. Vaya a **Seguridad** → **Administrators**.
    2. Haga clic en **Add administrator** y seleccione el usuario del paso anterior.
    3. Asigne el rol **Read-only Administrator**.
    4. Haga clic en Guardar.

    <Note>
      Sin un rol de administrador, las llamadas a la Okta Management API se realizan correctamente con `200 OK` y devuelven una lista vacía. No hay ningún `403` que le indique que falta el rol: los flujos simplemente permanecen vacíos.
    </Note>
  </Step>

  <Step title="Cree el token de API">
    1. Inicie sesión en la Admin Console **como el usuario de la cuenta de servicio** del paso 1. El token hereda los permisos de la cuenta que lo crea.
    2. Vaya a **Seguridad** → **API** y abra la pestaña **Tokens**.
    3. Haga clic en **Create token**, asígnele un nombre como `Living Security Platform` y haga clic en **Create token**.
    4. Copie ahora el valor del token: Okta lo muestra una sola vez y no vuelve a mostrarlo.

    <Warning>
      Okta desactiva un token de API tras **30 días sin uso**. Las sincronizaciones de esta integración se ejecutan al menos una vez al día, por lo que una conexión activa mantiene vigente su propio token. Una conexión que permanezca en pausa durante un mes necesitará un token nuevo.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      La lista de direcciones anterior solo es relevante si su organización de Okta restringe el acceso a la API mediante **zonas de red**. La mayoría de las organizaciones no lo hace.
    </Note>
  </Step>

  <Step title="Localice el subdominio de su tenant">
    La URL de su Admin Console tiene este aspecto: `https://acme-admin.okta.com`. El subdominio del tenant es `acme`, sin el sufijo `-admin`, sin `.okta.com` y sin `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Campo | Valor |
    | - | - |
    | **Clave de API** | El token de API del paso 3 |
    | **Subdominio del tenant** | El subdominio del paso 4 (por ejemplo, `acme`) |
  </ConnectInPlatform>
</Steps>

Ya está conectado a Okta (SSWS).

### Solución de problemas

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    El token no es válido, fue revocado o se desactivó tras 30 días de inactividad. Cree un token nuevo como el usuario de la cuenta de servicio y vuelva a introducirlo en la conexión.
  </Accordion>

  <Accordion title="Conectado, pero todos los flujos están vacíos">
    El propietario del token no tiene ningún rol de administrador. Asigne **Read-only Administrator** a la cuenta de servicio (paso 2): cuando falta el rol, la API devuelve `200 OK` con una lista vacía en lugar de un error.
  </Accordion>

  <Accordion title="Las sincronizaciones fallan tras un cambio de personal">
    El token deja de funcionar si se desactiva al usuario que lo creó. Por eso el token debe pertenecer a una cuenta de servicio y no a una persona.
  </Accordion>
</AccordionGroup>

***

## Opción B: aplicación de servicio OAuth 2.0

Utilice este método cuando su política de seguridad no permita tokens de API de larga duración. Sustituye el token por un ID de cliente y un par de claves RSA de su propiedad. En la plataforma, corresponde al icono **Okta (OAuth 2.0)**, en **Configuración → Integraciones → Catálogo**.

Para autenticarse con Okta mediante Client Credentials, necesita lo siguiente:

1. **ID de cliente**: un identificador único para su aplicación Okta API Services.
2. **Clave privada (JWK)**: la clave privada RSA en formato JSON Web Key, cuya clave pública está registrada en su aplicación de Okta.
3. **Dominio de Okta**: solo el subdominio de su tenant de Okta (por ejemplo, `dev-12345678`), no el nombre de host completo.
4. **Ámbitos**: una lista de ámbitos de la Okta Management API separados por espacios (por ejemplo, `okta.users.read okta.logs.read`).

Esta guía le explica cómo crear en Okta una aplicación API Services con autenticación `private_key_jwt`.

### Requisitos previos:

* Debe tener una cuenta de Okta. Puede registrarse para obtener una cuenta de desarrollador gratuita en [developer.okta.com](https://developer.okta.com/signup/).

#### Paso 1: Cree su aplicación Okta API Services

1. Inicie sesión en su [Okta Admin Console](https://login.okta.com/).
2. En la barra lateral izquierda, vaya a **Applications** > **Applications**.
3. Haga clic en **Create App Integration**.
4. Seleccione **API Services** como método de inicio de sesión y haga clic en **Siguiente**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-api-service.png" style={{maxWidth: "550px"}} />

5. Asigne un nombre a su aplicación y haga clic en **Guardar**.
6. En la pestaña **General** de la aplicación, localice su **ID de cliente**; lo necesitará en el paso final.
7. Establezca Client authentication en **Public key / Private key**. Los ámbitos `okta.*` solo son compatibles con este método de autenticación.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-public-private-key.png" style={{maxWidth: "550px"}} />

8. Desactive **Proof of possession (DPoP)**, ya que no es compatible.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/disable-dpop.png" style={{maxWidth: "550px"}} />

<Note>
  La aplicación debe crearse como **API Services**.
</Note>

#### Paso 2: Genere y registre su par de claves RSA

##### Use el generador de claves de Okta

Okta puede generar el par de claves RSA por usted directamente en la Admin Console:

1. En la Admin Console, abra su aplicación API Services.
2. Vaya a la pestaña **General** y desplácese hasta la sección **PUBLIC KEYS**.
3. Haga clic en **Add Key** y, a continuación, seleccione **Generate new key**.
4. Haga clic en **Guardar**: Okta genera el par de claves y muestra la **clave privada (JWK)** una sola vez.
5. Copie y guarde de inmediato el JSON de la clave privada; no se volverá a mostrar.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/create-public-key.png" style={{maxWidth: "550px"}} />

6. La clave pública se registra automáticamente en su aplicación.

<Note>
  Copie la JWK privada antes de cerrar el cuadro de diálogo. Péguela en el campo **Clave privada** de Living Security Platform en el paso final.
</Note>

##### Cree su propia clave

Okta utiliza `private_key_jwt` para las aplicaciones API Services. Usted genera un par de claves RSA, registra la JWK **pública** en Okta y proporciona la JWK **privada** a Living Security Platform.

**Genere una JWK privada** con el siguiente script de Node.js (requiere Node.js 18+):

```javascript theme={null}
const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });

const privateJwk = privateKey.export({ format: 'jwk' });
const publicJwk  = publicKey.export({ format: 'jwk' });

// Assign a kid — must match between private and public JWK
const kid = require('crypto').randomUUID();
privateJwk.kid = kid;
publicJwk.kid  = kid;

console.log('=== PUBLIC JWK (upload to Okta) ===');
console.log(JSON.stringify(publicJwk, null, 2));
console.log('\n=== PRIVATE JWK (paste into the Living Security Platform) ===');
console.log(JSON.stringify(privateJwk));
```

**Registre la JWK pública en Okta:**

1. En la Admin Console, abra su aplicación API Services.
2. Vaya a la pestaña **General** y desplácese hasta la sección **PUBLIC KEYS**.
3. Haga clic en **Add Key**, pegue el **JSON de la JWK pública** generado por el script anterior y haga clic en **Guardar**.

<Note>
  La JWK privada es la que pega en Living Security Platform. Incluye todo el material de la clave (`d`, `p`, `q`, `dp`, `dq`, `qi`) y el `kid`. Manténgala en secreto.
</Note>

#### Paso 3: Localice su dominio de Okta

Introduzca únicamente el subdominio de su tenant de Okta: la parte anterior a `.okta.com`.

* En la Admin Console, la barra de direcciones del navegador mostrará una URL como `https://dev-12345678-admin.okta.com`.
* Su **Dominio de Okta** es solo el subdominio (por ejemplo, `dev-12345678`), no `dev-12345678.okta.com`.
* Como alternativa, vaya a **Configuración** > **Account** en la Admin Console para encontrar su dominio de Okta y utilice la parte del subdominio.

#### Paso 4: Conceda ámbitos de API a su aplicación

Okta exige al menos un ámbito en cada solicitud de token. Antes de que su aplicación pueda solicitar ámbitos específicos, estos deben estar concedidos:

1. En la Admin Console, vaya a **Applications** > **Applications** y abra su aplicación.
2. Haga clic en la pestaña **Okta API Scopes**.
3. Conceda los ámbitos que requiere su integración: `okta.users.read` y `okta.logs.read`.

Encontrará una lista completa de los ámbitos disponibles en la [referencia de Okta Management API](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Paso 5: Asigne un rol de administrador a su aplicación

Conceder ámbitos no es suficiente: los endpoints de la Okta Management API (por ejemplo, `/api/v1/users`) devuelven silenciosamente una respuesta `200 []` vacía si su aplicación no tiene un rol de administrador. Debe asignar como mínimo **Read-Only Administrator**:

1. En la Admin Console, vaya a **Seguridad** > **Administrators** (o a **Applications** > **Applications** > su aplicación > **Admin roles**).
2. Haga clic en **Add administrator assignment** y seleccione su aplicación API Services.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/admin-role-dropdown.png" style={{maxWidth: "550px"}} />

3. Asigne el rol **Read-Only Administrator** (o superior, según los ámbitos que necesite).
4. Haga clic en **Guardar**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/add-admin-role.png" style={{maxWidth: "550px"}} />

<Note>
  Sin un rol de administrador, las llamadas a la API se realizan correctamente con `200 OK` pero devuelven resultados vacíos, y no hay ningún error `403` que indique el problema.
</Note>

#### Paso 6: Introduzca las credenciales en Living Security Platform

Una vez que disponga de su **ID de cliente**, su **clave privada (JWK)**, su **dominio de Okta** y sus **ámbitos**:

1. Abra el formulario en el que necesite autenticarse con Okta (Client Credentials).
2. Introduzca su **ID de cliente**.
3. Pegue su **clave privada (JWK)**: el objeto JSON completo del script anterior (en una sola línea o con formato).
4. Introduzca su **dominio de Okta** solo como el subdominio del tenant (por ejemplo, `dev-12345678`).
5. Introduzca los **ámbitos** como una lista separada por espacios (por ejemplo, `okta.users.read okta.logs.read`).
6. Envíe el formulario y debería quedar autenticado correctamente.

Ya está conectado a Okta (Client Credentials).

***

<Note>Partes de esta documentación están adaptadas de [Nango](https://nango.dev/docs/), utilizada bajo la [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme).</Note>

<PublicIntegrationNextSteps />


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.