> ## 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'AMF et l'activité administrative.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Ressources connexes</h2>
    <ul>
      <li>
        <a href="/fr-CA/signals/data-sources">Découvrez comment les données d'intégration deviennent des signaux de gestion des risques humains</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Découvrez 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 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 des 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-CA/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 des conseils de dépannage.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Saisissez les identifiants dans la Living Security Platform">
    <p>
      Cette étape est réalisée par la personne qui détient 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 tuile{' '}
        <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>;

## Aperçu

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

* `account.locked` — compte verrouillé
* `mfa.factor.activated` — active des facteurs d'AMF supplémentaires
* `auth.login.failed` — échoue à ouvrir une session

Les deux méthodes de connexion lisent les deux mêmes flux : le répertoire 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-CA/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 JWK privée que vous générez et enregistrez |
| Configuration | Trois étapes, aucun matériel de clé à générer | Neuf étapes, y compris 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; il vous revient d'effectuer la rotation de la paire de clés |
| À 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 le même 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ée.*

### 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 locataire** | Le `<tenant>` dans `<tenant>.okta.com` — le sous-domaine seul, 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 possède les 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 d'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 qu'un accès en lecture confère 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 de gestion d'Okta réussissent avec `200 OK` et renvoient une liste vide. Aucun `403` ne vous signale l'absence du rôle : 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 dès maintenant la valeur du jeton : Okta l'affiche 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'importe que si votre organisation Okta restreint l'accès à l'API par **zone réseau**. La plupart des organisations ne le font pas.
    </Note>
  </Step>

  <Step title="Trouver le sous-domaine de votre locataire">
    L'URL de votre console d'administration ressemble à `https://acme-admin.okta.com`. Le sous-domaine du locataire 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 locataire** | Le sous-domaine de l'étape 4 (p. 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 de 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 absent.
  </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 tuile **Okta (OAuth 2.0)**, sous **Paramètres → Intégrations → Catalogue**.

Pour vous authentifier auprès d'Okta à l'aide des identifiants client (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 locataire Okta (p. ex. `dev-12345678`), et non le nom d'hôte complet.
4. **Portées** - Une liste de portées de l'API de gestion d'Okta séparées par des espaces (p. 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 avoir un compte Okta. Inscrivez-vous pour obtenir un compte développeur gratuit à l'adresse [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 et 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 et cliquez sur **Sauver**.
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 **Sauver** : Okta génère la paire de clés et affiche la **clé privée (JWK)** une seule fois.
5. Copiez et conservez 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 JWK privée avant de fermer la boîte de dialogue. Collez-la dans le champ **Clé privée** de 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 JWK **publique** auprès d'Okta et fournissez la JWK **privée** à Living Security Platform.

**Générez une JWK privée** à l'aide du script Node.js suivant (nécessite 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));
```

**Enregistrez la 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 JWK publique** produit par le script ci-dessus, puis cliquez sur **Sauver**.

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

#### Étape 3 : Recherche de votre domaine Okta

Saisissez uniquement le sous-domaine de votre locataire Okta, soit la partie qui précède `.okta.com`.

* Dans la console d'administration, la barre d'adresse de votre navigateur affiche une URL semblable à `https://dev-12345678-admin.okta.com`.
* Votre **domaine Okta** est uniquement le sous-domaine (p. ex. `dev-12345678`), et non `dev-12345678.okta.com`.
* Vous pouvez aussi 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 précises, celles-ci doivent lui ê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 de gestion d'Okta](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 de gestion d'Okta (p. 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 moins **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 supérieur, selon les portées dont vous avez besoin).
4. Cliquez sur **Sauver**.

<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 : Saisie des identifiants dans 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 où 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** sous la forme du sous-domaine du locataire uniquement (p. ex. `dev-12345678`).
5. Saisissez les **portées** sous forme de liste séparée par des espaces (p. ex. `okta.users.read okta.logs.read`).
6. Soumettez le formulaire; l'authentification devrait alors réussir.

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

***

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