> ## 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ó de la integració d'Okta

> Connecteu Okta a Living Security per obtenir activitat del cicle de vida dels usuaris, d'autenticació, d'MFA i d'administració.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Recursos relacionats</h2>
    <ul>
      <li>
        <a href="/ca/signals/data-sources">Descobriu com les dades d'integració es converteixen en Signals de Human Risk Management</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Exploreu les Integrations de Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Obriu la Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Sol·liciteu una demostració de Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Afegiu les quatre adreces IP de sortida de sincronització de Living Security</strong> a la llista d'adreces permeses de{' '}
    {system}. Introduïu-les cadascuna com a host únic amb <code>/32</code> si {system} espera notació 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ànsit pot sortir per qualsevol de les quatre, de manera que, si només'n permeteu algunes, es produeixen errors de
    sincronització intermitents. Aquestes quatre adreces són les mateixes a totes les regions de Living Security. Consulteu{' '}
    <a href="/ca/integrations/managing/egress-ip-addresses">
      Configuring Integration Egress IP Addresses
    </a>{' '}
    per obtenir la llista completa, la política de canvis i la resolució de problemes.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Introduïu les credencials a la Living Security Platform">
    <p>
      Ho ha de dur a terme qui tingui accés a Living Security: el responsable del programa o
      l'administrador del sistema, si ha estat convidat (configuració delegada).
    </p>
    <ol>
      <li>
        Aneu a <strong>Settings → Integrations → Catalog</strong>, cerqueu la icona de{' '}
        <strong>{tile}</strong> i feu clic a <strong>Connect</strong>.
      </li>
      <li>
        Ompliu els camps següents i, a continuació, feu clic a <strong>Connect</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Overview

Okta pot aportar activitat normalitzada del cicle de vida dels usuaris, d'autenticació, d'MFA i d'administració. Alguns exemples revisats són:

* `account.locked` — compte bloquejat
* `mfa.factor.activated` — activa factors d'MFA addicionals
* `auth.login.failed` — no pot iniciar la sessió

Tots dos mètodes de connexió llegeixen els mateixos dos fluxos: el directori d'usuaris (`/api/v1/users`) i el registre del sistema (`/api/v1/logs`). Consulteu [com les dades d'integració es converteixen en Signals](/ca/signals/data-sources).

## Trieu un mètode de connexió

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Credencial | Un token d'API que creeu a l'Admin Console | Un ID de client i una JWK privada que genereu i registreu |
| Configuració | Tres passos, sense material de claus per generar | Nou passos, inclòs un parell de claus RSA |
| Rol d'administrador requerit | Administrador de només lectura, assignat al propietari del token | Administrador de només lectura, assignat a l'aplicació |
| Durada del token | Es desactiva després de 30 dies sense ús | No caduca; la rotació del parell de claus és responsabilitat vostra |
| Useu-lo quan | És el camí recomanat per a la majoria d'organitzacions | La vostra política de seguretat prohibeix els tokens d'API de llarga durada |

Tots dos mètodes necessiten el mateix accés, de manera que l'elecció depèn de la gestió de les credencials, no del que la plataforma pot llegir.

***

## Opció A — Token d'API (SSWS)

*Recomanada.*

### Què necessita Living Security

| Credencial | Descripció |
| - | - |
| **API key** | Un token d'API d'Okta. El diàleg de connexió anomena aquest camp **API key** |
| **Tenant subdomain** | El `<tenant>` de `<tenant>.okta.com`: només el subdomini, no l'URL completa |

### Requisits previs

* Heu de ser **Super Administrator** d'Okta per crear un usuari de compte de servei, assignar rols d'administrador i crear tokens d'API.

<Steps>
  <Step title="Creeu un usuari propietari del token">
    Un token d'API d'Okta té els permisos de l'usuari que l'ha creat i deixa de funcionar si aquest usuari es desactiva. Creeu un compte de servei dedicat en lloc d'utilitzar un compte d'administrador personal, de manera que la connexió sobrevisqui als canvis de personal.

    1. A l'Admin Console, aneu a **Directory** → **People**.
    2. Feu clic a **Add person** i creeu un usuari com ara `svc-livingsecurity@yourcompany.com`.
    3. Activeu el compte.
  </Step>

  <Step title="Assigneu el rol d'administrador de només lectura">
    La plataforma només llegeix. Concedir més que accés de lectura dona al token permisos que no utilitzarà mai.

    1. Aneu a **Security** → **Administrators**.
    2. Feu clic a **Add administrator** i seleccioneu l'usuari del pas anterior.
    3. Assigneu el rol **Read-only Administrator**.
    4. Deseu els canvis.

    <Note>
      Sense un rol d'administrador, les crides a l'API Management d'Okta s'completen amb `200 OK` i retornen una llista buida. No hi ha cap `403` que indiqui que falta el rol: els fluxos simplement queden buits.
    </Note>
  </Step>

  <Step title="Creeu el token d'API">
    1. Inicieu la sessió a l'Admin Console **com a l'usuari del compte de servei** del pas 1. El token hereta els permisos del compte que el crea.
    2. Aneu a **Security** → **API** i obriu la pestanya **Tokens**.
    3. Feu clic a **Create token**, poseu-li un nom com ara `Living Security Platform` i feu clic a **Create token**.
    4. Copieu ara el valor del token: Okta el mostra una sola vegada i no el tornarà a mostrar.

    <Warning>
      Okta desactiva un token d'API després de **30 dies sense ús**. Les sincronitzacions d'aquesta integració s'executen almenys un cop al dia, de manera que una connexió activa manté viu el seu token. Una connexió que es deixi en pausa durant un mes necessitarà un token nou.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      La llista d'adreces anterior només és rellevant si la vostra organització d'Okta restringeix l'accés a l'API per **network zone**. La majoria d'organitzacions no ho fan.
    </Note>
  </Step>

  <Step title="Cerqueu el subdomini del vostre tenant">
    L'URL de l'Admin Console té un aspecte com `https://acme-admin.okta.com`. El subdomini del tenant és `acme`, sense el sufix `-admin`, sense `.okta.com` i sense `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Camp | Valor |
    | - | - |
    | **API key** | El token d'API del pas 3 |
    | **Tenant subdomain** | El subdomini del pas 4 (p. ex. `acme`) |
  </ConnectInPlatform>
</Steps>

Ara esteu connectat a Okta (SSWS).

### Resolució de problemes

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    El token no és vàlid, s'ha revocat o s'ha desactivat després de 30 dies d'inactivitat. Creeu un token nou com a usuari del compte de servei i torneu-lo a introduir a la connexió.
  </Accordion>

  <Accordion title="Connectat, però tots els fluxos són buits">
    El propietari del token no té cap rol d'administrador. Assigneu **Read-only Administrator** al compte de servei (pas 2): l'API retorna `200 OK` amb una llista buida en lloc d'un error quan falta el rol.
  </Accordion>

  <Accordion title="Les sincronitzacions fallen després d'un canvi de personal">
    El token deixa de funcionar si l'usuari que el va crear es desactiva. Per això el token ha de pertànyer a un compte de servei i no a una persona.
  </Accordion>
</AccordionGroup>

***

## Opció B — Aplicació de servei OAuth 2.0

Utilitzeu aquest mètode quan la vostra política de seguretat no permeti tokens d'API de llarga durada. Substitueix el token per un ID de client i un parell de claus RSA que són vostres. A la plataforma és el mosaic **Okta (OAuth 2.0)**, a **Settings → Integrations → Catalog**.

Per autenticar-vos amb Okta mitjançant Client Credentials, necessiteu el següent:

1. **Client ID** - Un identificador únic per a la vostra aplicació Okta API Services.
2. **Private Key (JWK)** - La clau privada RSA en format JSON Web Key, la clau pública de la qual està registrada a la vostra aplicació d'Okta.
3. **Okta Domain** - Només el subdomini del vostre tenant d'Okta (p. ex. `dev-12345678`), no el nom d'amfitrió complet.
4. **Scopes** - Una llista d'àmbits de l'API Management d'Okta separats per espais (p. ex. `okta.users.read okta.logs.read`).

Aquesta guia us explicarà com crear una aplicació API Services a Okta amb autenticació `private_key_jwt`.

### Requisits previs:

* Heu de tenir un compte d'Okta. Podeu registrar-vos per obtenir un compte de desenvolupador gratuït a [developer.okta.com](https://developer.okta.com/signup/).

#### Pas 1: Creació de l'aplicació Okta API Services

1. Inicieu la sessió a l'[Okta Admin Console](https://login.okta.com/).
2. A la barra lateral esquerra, aneu a **Applications** > **Applications**.
3. Feu clic a **Create App Integration**.
4. Seleccioneu **API Services** com a mètode d'inici de sessió i feu clic a **Next**.

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

5. Poseu un nom a l'aplicació i feu clic a **Save**.
6. A la pestanya **General** de l'aplicació, cerqueu el **Client ID**: el necessitareu en el pas final.
7. Establiu Client authentication a **Public key / Private key**. Els àmbits `okta.*` només són compatibles amb aquest mètode d'autenticació.

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

8. Desactiveu **Proof of possession (DPoP)**: no és compatible.

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

<Note>
  L'aplicació s'ha de crear com a **API Services**.
</Note>

#### Pas 2: Generació i registre del parell de claus RSA

##### Utilitzeu el generador de claus d'Okta

Okta pot generar el parell de claus RSA directament a l'Admin Console:

1. A l'Admin Console, obriu la vostra aplicació API Services.
2. Aneu a la pestanya **General** i desplaceu-vos fins a la secció **PUBLIC KEYS**.
3. Feu clic a **Add Key** i, a continuació, seleccioneu **Generate new key**.
4. Feu clic a **Save**: Okta genera el parell de claus i mostra la **Private Key (JWK)** una sola vegada.
5. Copieu i deseu immediatament el JSON de la clau privada: no es tornarà 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 clau pública es registra automàticament a la vostra aplicació.

<Note>
  Copieu la JWK privada abans de tancar el diàleg. Enganxeu-la al camp **Private Key** de la Living Security Platform en el pas final.
</Note>

##### Creeu la vostra pròpia clau

Okta utilitza `private_key_jwt` per a les aplicacions API Services. Genereu un parell de claus RSA, registreu la JWK **pública** a Okta i proporcioneu la JWK **privada** a la Living Security Platform.

**Genereu una JWK privada** amb el script de Node.js següent (requereix 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));
```

**Registreu la JWK pública a Okta:**

1. A l'Admin Console, obriu la vostra aplicació API Services.
2. Aneu a la pestanya **General** i desplaceu-vos fins a la secció **PUBLIC KEYS**.
3. Feu clic a **Add Key**, enganxeu el **JSON de la JWK pública** generat pel script anterior i feu clic a **Save**.

<Note>
  La JWK privada és la que enganxeu a la Living Security Platform. Inclou tot el material de la clau (`d`, `p`, `q`, `dp`, `dq`, `qi`) i el `kid`. Mantingueu-la en secret.
</Note>

#### Pas 3: Cerca del vostre Okta Domain

Introduïu només el subdomini del vostre tenant d'Okta: la part anterior a `.okta.com`.

* A l'Admin Console, la barra d'adreces del navegador mostrarà un URL com `https://dev-12345678-admin.okta.com`.
* El vostre **Okta Domain** és només el subdomini (p. ex., `dev-12345678`), no `dev-12345678.okta.com`.
* Alternativament, aneu a **Settings** > **Account** a l'Admin Console per trobar el vostre domini d'Okta i feu servir la part del subdomini.

#### Pas 4: Concessió d'àmbits d'API a l'aplicació

Okta requereix almenys un àmbit a cada sol·licitud de token. Perquè l'aplicació pugui sol·licitar àmbits concrets, primer s'han de concedir:

1. A l'Admin Console, aneu a **Applications** > **Applications** i obriu la vostra aplicació.
2. Feu clic a la pestanya **Okta API Scopes**.
3. Concediu els àmbits que requereix la vostra integració: `okta.users.read` i `okta.logs.read`.

Trobareu una llista completa dels àmbits disponibles a la [referència de l'API Management d'Okta](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Pas 5: Assignació d'un rol d'administrador a l'aplicació

Concedir només àmbits no és suficient: els punts finals de l'API Management d'Okta (p. ex. `/api/v1/users`) retornen silenciosament una resposta `200 []` buida si l'aplicació no té cap rol d'administrador. Heu d'assignar com a mínim **Read-Only Administrator**:

1. A l'Admin Console, aneu a **Security** > **Administrators** (o aneu a **Applications** > **Applications** > la vostra aplicació > **Admin roles**).
2. Feu clic a **Add administrator assignment** i seleccioneu la vostra aplicació API Services.

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

3. Assigneu el rol **Read-Only Administrator** (o superior, segons els àmbits que necessiteu).
4. Feu clic a **Save**.

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

<Note>
  Sense un rol d'administrador, les crides a l'API s'completen amb `200 OK` però retornen resultats buits i no hi ha cap error `403` que indiqui el problema.
</Note>

#### Pas 6: Introducció de les credencials a la Living Security Platform

Quan tingueu el **Client ID**, la **Private Key (JWK)**, l'**Okta Domain** i els **Scopes**:

1. Obriu el formulari on heu d'autenticar-vos amb Okta (Client Credentials).
2. Introduïu el vostre **Client ID**.
3. Enganxeu la vostra **Private Key (JWK)**: l'objecte JSON complet del script anterior (en una sola línia o amb format).
4. Introduïu el vostre **Okta Domain** només com a subdomini del tenant (p. ex., `dev-12345678`).
5. Introduïu els **Scopes** com a llista separada per espais (p. ex., `okta.users.read okta.logs.read`).
6. Envieu el formulari i hauríeu d'autenticar-vos correctament.

Ara esteu connectat a Okta (Client Credentials).

***

<Note>Parts d'aquesta documentació s'han adaptat de [Nango](https://nango.dev/docs/), utilitzat sota 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.