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

# Opsætning af Okta-integration

> Forbind Okta med Living Security for brugerlivscyklus, godkendelse, MFA og administrativ aktivitet.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Relaterede ressourcer</h2>
    <ul>
      <li>
        <a href="/da/signals/data-sources">Læs, hvordan integrationsdata bliver til Human Risk Management-signaler</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Udforsk integrationer fra Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Åbn Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Anmod om en demo af Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Føj alle fire udgående IP-adresser for Living Security-synkronisering</strong> til tilladelseslisten i{' '}
    {system}. Angiv hver adresse som en enkelt vært med <code>/32</code>, hvis {system} forventer CIDR-notation:
    <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 />
    Trafikken kan udgå fra en vilkårlig af de fire adresser, så hvis kun nogle af dem føjes til tilladelseslisten, medfører det periodiske
    synkroniseringsfejl. Disse fire adresser er de samme i alle Living Security-regioner. Se{' '}
    <a href="/da/integrations/managing/egress-ip-addresses">
      Konfiguration af udgående IP-adresser for Integrationer
    </a>{' '}
    for den fulde liste, ændringspolitik og fejlfinding.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Angiv legitimationsoplysningerne i Living Security Platform">
    <p>
      Udføres af den person, der har Living Security-adgang – programejeren eller
      systemadministratoren, hvis vedkommende er blevet inviteret (delegeret opsætning).
    </p>
    <ol>
      <li>
        Gå til <strong>Indstillinger → integrationer → katalog</strong>, find feltet{' '}
        <strong>{tile}</strong>, og klik på <strong>Tilslut</strong>.
      </li>
      <li>
        Udfyld felterne nedenfor, og klik derefter på <strong>Tilslut</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Oversigt

Okta kan bidrage med normaliseret data om brugerlivscyklus, godkendelse, MFA og administrativ aktivitet. Gennemgåede eksempler omfatter:

* `account.locked` — konto låst
* `mfa.factor.activated` — aktiverer yderligere MFA-faktorer
* `auth.login.failed` — kan ikke logge på

Begge forbindelsesmetoder læser de samme to datastrømme — brugerkataloget (`/api/v1/users`) og systemloggen (`/api/v1/logs`). Se [hvordan integrationsdata bliver til signaler](/da/signals/data-sources).

## Vælg en forbindelsesmetode

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Legitimationsoplysning | Et API-token, som du opretter i Admin Console | Et klient-id og en privat JWK, som du selv genererer og registrerer |
| Opsætning | Tre trin, ingen nøglemateriale at generere | Ni trin, herunder et RSA-nøglepar |
| Påkrævet administratorrolle | Skrivebeskyttet administrator, tildelt tokenets ejer | Skrivebeskyttet administrator, tildelt applikationen |
| Tokens levetid | Deaktiveres efter 30 dages manglende brug | Udløber ikke; du har selv ansvaret for at rotere nøgleparret |
| Brug den, når | Dette er den anbefalede løsning for de fleste organisationer | Din sikkerhedspolitik forbyder langtidsholdbare API-tokens |

Begge metoder kræver samme adgang, så valget handler om håndtering af legitimationsoplysninger og ikke om, hvad platformen kan læse.

***

## Mulighed A — API-token (SSWS)

*Anbefalet.*

### Det skal Living Security bruge

| Legitimationsoplysning | Beskrivelse |
| - | - |
| **API-nøgle** | Et Okta API-token. Forbindelsesdialogen kalder dette felt **API-nøgle** |
| **Tenant-underdomæne** | `<tenant>` i `<tenant>.okta.com` — kun selve underdomænet, ikke den fulde URL |

### Forudsætninger

* Du skal være Okta **Super Administrator** for at oprette en servicekontobruger, tildele administratorroller og oprette API-tokens.

<Steps>
  <Step title="Opret en bruger, der ejer tokenet">
    Et Okta API-token har de samme rettigheder som den bruger, der har oprettet det, og det holder op med at virke, hvis brugeren deaktiveres. Opret en dedikeret servicekonto i stedet for at bruge en personlig administratorkonto, så forbindelsen overlever personaleændringer.

    1. Gå til **Directory** → **People** i Admin Console.
    2. Klik på **Add person**, og opret en bruger som f.eks. `svc-livingsecurity@yourcompany.com`.
    3. Aktivér kontoen.
  </Step>

  <Step title="Tildel rollen som skrivebeskyttet administrator">
    Platformen læser kun. Hvis du giver mere end læseadgang, får tokenet rettigheder, som det aldrig bruger.

    1. Gå til **Security** → **Administrators**.
    2. Klik på **Add administrator**, og vælg brugeren fra det forrige trin.
    3. Tildel rollen **Read-only Administrator**.
    4. Gem.

    <Note>
      Uden en administratorrolle lykkes kald til Okta Management API med `200 OK` og returnerer en tom liste. Der er ingen `403`, som fortæller dig, at rollen mangler — datastrømmene forbliver blot tomme.
    </Note>
  </Step>

  <Step title="Opret API-tokenet">
    1. Log på Admin Console **som servicekontobrugeren** fra trin 1. Tokenet arver rettighederne fra den konto, der opretter det.
    2. Gå til **Security** → **API**, og åbn fanen **Tokens**.
    3. Klik på **Create token**, giv det et navn som f.eks. `Living Security Platform`, og klik på **Create token**.
    4. Kopiér tokenværdien nu — Okta viser den kun én gang.

    <Warning>
      Okta deaktiverer et API-token efter **30 dages manglende brug**. Synkroniseringerne i denne integration kører mindst én gang om dagen, så en aktiv forbindelse holder selv sit token i live. En forbindelse, der har været sat på pause i en måned, kræver et nyt token.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Adresselisten ovenfor er kun relevant, hvis din Okta-organisation begrænser API-adgang via **netværkszone**. Det gør de fleste organisationer ikke.
    </Note>
  </Step>

  <Step title="Find dit tenant-underdomæne">
    Din Admin Console-URL ser ud som `https://acme-admin.okta.com`. Tenant-underdomænet er `acme` — uden suffikset `-admin`, uden `.okta.com` og uden `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Felt | Værdi |
    | - | - |
    | **API-nøgle** | API-tokenet fra trin 3 |
    | **Tenant-underdomæne** | Underdomænet fra trin 4 (f.eks. `acme`) |
  </ConnectInPlatform>
</Steps>

Du er nu forbundet til Okta (SSWS).

### Fejlfinding

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Tokenet er ugyldigt, er blevet tilbagekaldt eller er blevet deaktiveret efter 30 dages inaktivitet. Opret et nyt token som servicekontobrugeren, og angiv det igen på forbindelsen.
  </Accordion>

  <Accordion title="Forbundet, men alle datastrømme er tomme">
    Tokenets ejer har ingen administratorrolle. Tildel **Read-only Administrator** til servicekontoen (trin 2) — API'et returnerer `200 OK` med en tom liste i stedet for en fejl, når rollen mangler.
  </Accordion>

  <Accordion title="Synkroniseringer fejler efter en personaleændring">
    Tokenet holder op med at virke, hvis den bruger, der har oprettet det, deaktiveres. Derfor bør tokenet tilhøre en servicekonto og ikke en person.
  </Accordion>
</AccordionGroup>

***

## Mulighed B — OAuth 2.0-serviceapplikation

Brug denne metode, når din sikkerhedspolitik ikke tillader langtidsholdbare API-tokens. Den erstatter tokenet med et klient-id og et RSA-nøglepar, som du selv ejer. I platformen er dette feltet **Okta (OAuth 2.0)** under **Indstillinger → integrationer → katalog**.

For at autentificere med Okta via Client Credentials skal du bruge følgende:

1. **Klient-id** - En unik identifikator for din Okta API Services-applikation.
2. **Privat nøgle (JWK)** - Den private RSA-nøgle i JSON Web Key-format, hvis offentlige nøgle er registreret i din Okta-applikation.
3. **Okta-domæne** - Kun dit Okta-tenant-underdomæne (f.eks. `dev-12345678`), ikke det fulde værtsnavn.
4. **Scopes** - En mellemrumsadskilt liste over Okta Management API-scopes (f.eks. `okta.users.read okta.logs.read`).

Denne vejledning fører dig gennem oprettelsen af en API Services-applikation i Okta med `private_key_jwt`-autentificering.

### Forudsætninger:

* Du skal have en Okta-konto. Tilmeld dig en gratis udviklerkonto på [developer.okta.com](https://developer.okta.com/signup/).

#### Trin 1: Opret din Okta API Services-applikation

1. Log ind på din [Okta Admin Console](https://login.okta.com/).
2. Gå til **Applications** > **Applications** i venstre sidebjælke.
3. Klik på **Create App Integration**.
4. Vælg **API Services** som log ind-metode, og klik på **Næste**.

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

5. Giv din applikation et navn, og klik på **Gem**.
6. Find dit **klient-id** på applikationens fane **General** — du skal bruge det i det sidste trin.
7. Sæt Client authentication til **Public key / Private key**. `okta.*`-scopes understøttes kun med denne autentificeringsmetode.

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

8. Deaktivér **Proof of possession (DPoP)** — det understøttes ikke.

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

<Note>
  Applikationen skal oprettes som **API Services**.
</Note>

#### Trin 2: Generér og registrér dit RSA-nøglepar

##### Brug Oktas nøglegenerator

Okta kan generere RSA-nøgleparret for dig direkte i Admin Console:

1. Åbn din API Services-applikation i Admin Console.
2. Gå til fanen **General**, og rul ned til afsnittet **PUBLIC KEYS**.
3. Klik på **Add Key**, og vælg derefter **Generate new key**.
4. Klik på **Gem** — Okta genererer nøgleparret og viser den **private nøgle (JWK)** én gang.
5. Kopiér og gem den private nøgle-JSON med det samme — den vises ikke igen.

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

6. Den offentlige nøgle registreres automatisk i din applikation.

<Note>
  Kopiér den private JWK, før du lukker dialogen. Indsæt den i feltet **Privat nøgle** i Living Security Platform i det sidste trin.
</Note>

##### Opret din egen nøgle

Okta bruger `private_key_jwt` til API Services-apps. Du genererer et RSA-nøglepar, registrerer den **offentlige** JWK hos Okta og angiver den **private** JWK til Living Security Platform.

**Generér en privat JWK** med følgende Node.js-script (kræver 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));
```

**Registrér den offentlige JWK i Okta:**

1. Åbn din API Services-applikation i Admin Console.
2. Gå til fanen **General**, og rul ned til afsnittet **PUBLIC KEYS**.
3. Klik på **Add Key**, indsæt den **offentlige JWK-JSON**, som scriptet ovenfor udskriver, og klik på **Gem**.

<Note>
  Den private JWK er den, du indsætter i Living Security Platform. Den indeholder alt nøglemateriale (`d`, `p`, `q`, `dp`, `dq`, `qi`) og `kid`. Hold den hemmelig.
</Note>

#### Trin 3: Find dit Okta-domæne

Angiv kun dit Okta-tenant-underdomæne — den del, der står før `.okta.com`.

* I Admin Console viser browserens adresselinje en URL som `https://dev-12345678-admin.okta.com`.
* Dit **Okta-domæne** er kun underdomænet (f.eks. `dev-12345678`), ikke `dev-12345678.okta.com`.
* Du kan også gå til **Indstillinger** > **Account** i Admin Console for at finde dit Okta-domæne og derefter bruge underdomænedelen.

#### Trin 4: Giv din applikation API-scopes

Okta kræver mindst ét scope i hver tokenanmodning. Før din applikation kan anmode om bestemte scopes, skal de tildeles:

1. Gå til **Applications** > **Applications** i Admin Console, og åbn din applikation.
2. Klik på fanen **Okta API Scopes**.
3. Tildel de scopes, som din integration kræver: `okta.users.read` og `okta.logs.read`.

En komplet liste over tilgængelige scopes findes i [Okta Management API-referencen](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Trin 5: Tildel en administratorrolle til din applikation

Det er ikke nok at tildele scopes — endpoints i Okta Management API (f.eks. `/api/v1/users`) returnerer uden varsel et tomt `200 []`-svar, hvis din applikation ikke har nogen administratorrolle. Du skal tildele mindst **Read-Only Administrator**:

1. Gå til **Security** > **Administrators** i Admin Console (eller gå til **Applications** > **Applications** > din app > **Admin roles**).
2. Klik på **Add administrator assignment**, og vælg din API Services-applikation.

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

3. Tildel rollen **Read-Only Administrator** (eller højere, afhængigt af de scopes, du har brug for).
4. Klik på **Gem**.

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

<Note>
  Uden en administratorrolle lykkes API-kald med `200 OK`, men returnerer tomme resultater, og der er ingen `403`-fejl, der angiver problemet.
</Note>

#### Trin 6: Angiv legitimationsoplysninger i Living Security Platform

Når du har dit **klient-id**, din **private nøgle (JWK)**, dit **Okta-domæne** og dine **scopes**:

1. Åbn den formular, hvor du skal autentificere med Okta (Client Credentials).
2. Angiv dit **klient-id**.
3. Indsæt din **private nøgle (JWK)** — hele JSON-objektet fra scriptet ovenfor (på én linje eller formateret).
4. Angiv dit **Okta-domæne** som kun tenant-underdomænet (f.eks. `dev-12345678`).
5. Angiv **scopes** som en mellemrumsadskilt liste (f.eks. `okta.users.read okta.logs.read`).
6. Send formularen, og du bør nu være autentificeret.

Du er nu forbundet til Okta (Client Credentials).

***

<Note>Dele af denne dokumentation er tilpasset fra [Nango](https://nango.dev/docs/) og anvendes under [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.