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

# Configuration de l'intégration Okta

> Connectez Okta à Living Security pour le cycle de vie des utilisateurs, l'authentification, l'authentification multifacteur (MFA) et l'activité administrative.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Ressources associées</h2>
    <ul>
      <li>
        <a href="/fr/signals/data-sources">Découvrez comment les données d'intégration deviennent des signaux de Human Risk Management</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Découvrir les intégrations de Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Ouvrir la Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Demander une démonstration de Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Ajoutez les quatre adresses IP de sortie de synchronisation de Living Security</strong> à la liste d'autorisation dans{' '}
    {system}. Saisissez chacune d'elles comme un hôte unique avec <code>/32</code> si {system} attend la notation 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 />
    Le trafic peut provenir de n'importe laquelle de ces quatre adresses ; n'en autoriser que certaines entraîne donc des échecs de
    synchronisation intermittents. Ces quatre adresses sont les mêmes dans toutes les régions de Living Security. Consultez{' '}
    <a href="/fr/integrations/managing/egress-ip-addresses">
      Configuration des adresses IP de sortie des Intégrations
    </a>{' '}
    pour obtenir la liste complète, la politique de modification et les conseils de dépannage.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Saisissez les identifiants dans la Living Security Platform">
    <p>
      À effectuer par la personne disposant d'un accès à Living Security : le responsable du programme, ou
      l'administrateur système s'il a été invité (configuration déléguée).
    </p>
    <ol>
      <li>
        Accédez à <strong>Paramètres → Intégrations → Catalogue</strong>, repérez la vignette{' '}
        <strong>{tile}</strong>, puis cliquez sur <strong>Connecter</strong>.
      </li>
      <li>
        Renseignez les champs ci-dessous, puis cliquez sur <strong>Connecter</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Présentation

Okta peut fournir des données normalisées sur le cycle de vie des utilisateurs, l'authentification, la MFA et l'activité administrative. Voici quelques exemples examinés :

* `account.locked` — compte verrouillé
* `mfa.factor.activated` — active des facteurs MFA supplémentaires
* `auth.login.failed` — échoue à se connecter

Les deux méthodes de connexion lisent les deux mêmes flux : l'annuaire des utilisateurs (`/api/v1/users`) et le journal système (`/api/v1/logs`). Consultez [comment les données d'intégration deviennent des signaux](/fr/signals/data-sources).

## Choisir une méthode de connexion

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Identifiant | Un jeton d'API que vous créez dans la console d'administration | Un ID client et une clé JWK privée que vous générez et enregistrez |
| Configuration | Trois étapes, aucun matériel de clé à générer | Neuf étapes, dont une paire de clés RSA |
| Rôle d'administrateur requis | Administrateur en lecture seule, attribué au propriétaire du jeton | Administrateur en lecture seule, attribué à l'application |
| Durée de vie du jeton | Désactivé après 30 jours sans utilisation | Aucune expiration ; la rotation de la paire de clés vous incombe |
| À utiliser quand | Il s'agit de la méthode recommandée pour la plupart des organisations | Votre politique de sécurité interdit les jetons d'API de longue durée |

Les deux méthodes nécessitent les mêmes accès ; le choix porte donc sur la gestion des identifiants, et non sur ce que la plateforme peut lire.

***

## Option A — Jeton d'API (SSWS)

*Recommandé.*

### Ce dont Living Security a besoin

| Identifiant | Description |
| - | - |
| **Clé API** | Un jeton d'API Okta. La boîte de dialogue de connexion nomme ce champ **Clé API** |
| **Sous-domaine du tenant** | Le `<tenant>` dans `<tenant>.okta.com` — uniquement le sous-domaine, et non l'URL complète |

### Prérequis

* Vous devez être **Super Administrator** Okta pour créer un utilisateur de compte de service, attribuer des rôles d'administrateur et créer des jetons d'API.

<Steps>
  <Step title="Créer un utilisateur propriétaire du jeton">
    Un jeton d'API Okta hérite des autorisations de l'utilisateur qui l'a créé et cesse de fonctionner si cet utilisateur est désactivé. Créez un compte de service dédié plutôt que d'utiliser un compte administrateur personnel, afin que la connexion survive aux changements de personnel.

    1. Dans la console d'administration, accédez à **Directory** → **People**.
    2. Cliquez sur **Add person** et créez un utilisateur tel que `svc-livingsecurity@yourcompany.com`.
    3. Activez le compte.
  </Step>

  <Step title="Attribuer le rôle d'administrateur en lecture seule">
    La plateforme effectue uniquement des lectures. Accorder plus que l'accès en lecture donne au jeton des autorisations qu'il n'utilisera jamais.

    1. Accédez à **Security** → **Administrators**.
    2. Cliquez sur **Add administrator** et sélectionnez l'utilisateur de l'étape précédente.
    3. Attribuez le rôle **Read-only Administrator**.
    4. Enregistrez.

    <Note>
      Sans rôle d'administrateur, les appels à l'API Okta Management réussissent avec `200 OK` et renvoient une liste vide. Aucun `403` ne vous indique que le rôle est manquant : les flux restent simplement vides.
    </Note>
  </Step>

  <Step title="Créer le jeton d'API">
    1. Connectez-vous à la console d'administration **en tant qu'utilisateur du compte de service** de l'étape 1. Le jeton hérite des droits du compte qui le crée.
    2. Accédez à **Security** → **API** et ouvrez l'onglet **Tokens**.
    3. Cliquez sur **Create token**, donnez-lui un nom tel que `Living Security Platform`, puis cliquez sur **Create token**.
    4. Copiez la valeur du jeton maintenant : Okta ne l'affiche qu'une seule fois.

    <Warning>
      Okta désactive un jeton d'API après **30 jours sans utilisation**. Les synchronisations de cette intégration s'exécutent au moins une fois par jour ; une connexion active maintient donc son propre jeton actif. Une connexion laissée en pause pendant un mois nécessite un nouveau jeton.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      La liste d'adresses ci-dessus n'est pertinente que si votre organisation Okta restreint l'accès à l'API par **zone réseau**. C'est rarement le cas.
    </Note>
  </Step>

  <Step title="Trouver le sous-domaine de votre tenant">
    L'URL de votre console d'administration ressemble à `https://acme-admin.okta.com`. Le sous-domaine du tenant est `acme` — sans le suffixe `-admin`, sans `.okta.com` et sans `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Champ | Valeur |
    | - | - |
    | **Clé API** | Le jeton d'API de l'étape 3 |
    | **Sous-domaine du tenant** | Le sous-domaine de l'étape 4 (par ex. `acme`) |
  </ConnectInPlatform>
</Steps>

Vous êtes maintenant connecté à Okta (SSWS).

### Dépannage

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Le jeton est invalide, a été révoqué ou a été désactivé après 30 jours d'inactivité. Créez un nouveau jeton en tant qu'utilisateur du compte de service et saisissez-le à nouveau dans la connexion.
  </Accordion>

  <Accordion title="Connecté, mais tous les flux sont vides">
    Le propriétaire du jeton n'a aucun rôle d'administrateur. Attribuez **Read-only Administrator** au compte de service (étape 2) : l'API renvoie `200 OK` avec une liste vide, plutôt qu'une erreur, lorsque le rôle est manquant.
  </Accordion>

  <Accordion title="Les synchronisations échouent après un changement de personnel">
    Le jeton cesse de fonctionner si l'utilisateur qui l'a créé est désactivé. C'est pourquoi le jeton doit appartenir à un compte de service et non à une personne.
  </Accordion>
</AccordionGroup>

***

## Option B — Application de service OAuth 2.0

Utilisez cette méthode lorsque votre politique de sécurité n'autorise pas les jetons d'API de longue durée. Elle remplace le jeton par un ID client et une paire de clés RSA dont vous êtes propriétaire. Dans la plateforme, il s'agit de la vignette **Okta (OAuth 2.0)**, sous **Paramètres → Intégrations → Catalogue**.

Pour vous authentifier auprès d'Okta à l'aide de Client Credentials, vous avez besoin des éléments suivants :

1. **ID client** - Un identifiant unique pour votre application Okta API Services.
2. **Clé privée (JWK)** - La clé privée RSA au format JSON Web Key, dont la clé publique est enregistrée dans votre application Okta.
3. **Domaine Okta** - Uniquement le sous-domaine de votre tenant Okta (par ex. `dev-12345678`), et non le nom d'hôte complet.
4. **Portées** - Une liste, séparée par des espaces, de portées de l'API Okta Management (par ex. `okta.users.read okta.logs.read`).

Ce guide vous explique comment créer une application API Services dans Okta avec l'authentification `private_key_jwt`.

### Prérequis :

* Vous devez disposer d'un compte Okta. Créez un compte développeur gratuit sur [developer.okta.com](https://developer.okta.com/signup/).

#### Étape 1 : Création de votre application Okta API Services

1. Connectez-vous à votre [console d'administration Okta](https://login.okta.com/).
2. Dans la barre latérale gauche, accédez à **Applications** > **Applications**.
3. Cliquez sur **Create App Integration**.
4. Sélectionnez **API Services** comme méthode de connexion, puis cliquez sur **Suivant**.

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

5. Donnez un nom à votre application, puis cliquez sur **Sauvegarder**.
6. Dans l'onglet **General** de l'application, repérez votre **ID client** : vous en aurez besoin à la dernière étape.
7. Définissez Client authentication sur **Public key / Private key**. Les portées `okta.*` ne sont prises en charge qu'avec cette méthode d'authentification.

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

8. Désactivez **Proof of possession (DPoP)** : cette option n'est pas prise en charge.

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

<Note>
  L'application doit être créée en tant que **API Services**.
</Note>

#### Étape 2 : Génération et enregistrement de votre paire de clés RSA

##### Utiliser le générateur de clés d'Okta

Okta peut générer la paire de clés RSA pour vous directement dans la console d'administration :

1. Dans la console d'administration, ouvrez votre application API Services.
2. Accédez à l'onglet **General** et faites défiler jusqu'à la section **PUBLIC KEYS**.
3. Cliquez sur **Add Key**, puis sélectionnez **Generate new key**.
4. Cliquez sur **Sauvegarder** : Okta génère la paire de clés et affiche la **clé privée (JWK)** une seule fois.
5. Copiez et enregistrez immédiatement le JSON de la clé privée : il ne sera plus affiché.

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

6. La clé publique est automatiquement enregistrée auprès de votre application.

<Note>
  Copiez la clé JWK privée avant de fermer la boîte de dialogue. Collez-la dans le champ **Private Key** de la Living Security Platform à la dernière étape.
</Note>

##### Créer votre propre clé

Okta utilise `private_key_jwt` pour les applications API Services. Vous générez une paire de clés RSA, enregistrez la clé JWK **publique** auprès d'Okta et fournissez la clé JWK **privée** à la Living Security Platform.

**Générez une clé JWK privée** à l'aide du script Node.js suivant (Node.js 18 ou version ultérieure requis) :

```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));
```

**Enregistrez la clé JWK publique dans Okta :**

1. Dans la console d'administration, ouvrez votre application API Services.
2. Accédez à l'onglet **General** et faites défiler jusqu'à la section **PUBLIC KEYS**.
3. Cliquez sur **Add Key**, collez le **JSON de la clé JWK publique** produit par le script ci-dessus, puis cliquez sur **Sauvegarder**.

<Note>
  La clé JWK privée est celle que vous collez dans la Living Security Platform. Elle contient tout le matériel de clé (`d`, `p`, `q`, `dp`, `dq`, `qi`) ainsi que `kid`. Gardez-la secrète.
</Note>

#### Étape 3 : Trouver votre domaine Okta

Saisissez uniquement le sous-domaine de votre tenant Okta, c'est-à-dire la partie située avant `.okta.com`.

* Dans la console d'administration, la barre d'adresse de votre navigateur affiche une URL telle que `https://dev-12345678-admin.okta.com`.
* Votre **domaine Okta** est uniquement le sous-domaine (par ex. `dev-12345678`), et non `dev-12345678.okta.com`.
* Vous pouvez également accéder à **Paramètres** > **Account** dans la console d'administration pour trouver votre domaine Okta, puis utiliser la partie correspondant au sous-domaine.

#### Étape 4 : Accorder des portées d'API à votre application

Okta exige au moins une portée dans chaque demande de jeton. Avant que votre application puisse demander des portées spécifiques, celles-ci doivent être accordées :

1. Dans la console d'administration, accédez à **Applications** > **Applications** et ouvrez votre application.
2. Cliquez sur l'onglet **Okta API Scopes**.
3. Accordez les portées requises par votre intégration : `okta.users.read` et `okta.logs.read`.

Une liste complète des portées disponibles figure dans la [référence de l'API Okta Management](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Étape 5 : Attribuer un rôle d'administrateur à votre application

Accorder des portées ne suffit pas : les points de terminaison de l'API Okta Management (par ex. `/api/v1/users`) renvoient silencieusement une réponse `200 []` vide si votre application n'a aucun rôle d'administrateur. Vous devez attribuer au minimum **Read-Only Administrator** :

1. Dans la console d'administration, accédez à **Security** > **Administrators** (ou à **Applications** > **Applications** > votre application > **Admin roles**).
2. Cliquez sur **Add administrator assignment** et sélectionnez votre application API Services.

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

3. Attribuez le rôle **Read-Only Administrator** (ou un rôle supérieur, selon les portées dont vous avez besoin).
4. Cliquez sur **Sauvegarder**.

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

<Note>
  Sans rôle d'administrateur, les appels d'API réussissent avec `200 OK` mais renvoient des résultats vides, et aucune erreur `403` n'indique le problème.
</Note>

#### Étape 6 : Saisir les identifiants dans la Living Security Platform

Une fois que vous disposez de votre **ID client**, de votre **clé privée (JWK)**, de votre **domaine Okta** et de vos **portées** :

1. Ouvrez le formulaire dans lequel vous devez vous authentifier auprès d'Okta (Client Credentials).
2. Saisissez votre **ID client**.
3. Collez votre **clé privée (JWK)** : l'objet JSON complet produit par le script ci-dessus (sur une seule ligne ou mis en forme).
4. Saisissez votre **domaine Okta** en indiquant uniquement le sous-domaine du tenant (par ex. `dev-12345678`).
5. Saisissez les **portées** sous forme de liste séparée par des espaces (par ex. `okta.users.read okta.logs.read`).
6. Envoyez le formulaire ; vous devriez être authentifié avec succès.

Vous êtes maintenant connecté à Okta (Client Credentials).

***

<Note>Certaines parties de cette documentation sont adaptées de [Nango](https://nango.dev/docs/), utilisée sous la [licence 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.