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

# Oppsett av Okta-integrasjon

> Koble Okta til Living Security for brukerlivssyklus, autentisering, MFA og administrativ aktivitet.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Relaterte ressurser</h2>
    <ul>
      <li>
        <a href="/no/signals/data-sources">Les hvordan data fra integrasjoner blir til signaler i Human Risk Management</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Utforsk integrasjonene til Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Åpne Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Be om en demo av Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Legg til alle fire utgående IP-adresser for Living Security-synkronisering</strong> i tillatelseslisten i{' '}
    {system}. Angi hver adresse som én enkelt vert med <code>/32</code> hvis {system} forventer CIDR-notasjon:
    <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 komme fra hvilken som helst av de fire adressene, så hvis bare noen av dem settes på tillatelseslisten, oppstår det periodiske synkroniseringsfeil. Disse fire adressene er de samme i alle Living Security-regioner. Se{' '}
    <a href="/no/integrations/managing/egress-ip-addresses">
      Konfigurere utgående IP-adresser for integrasjoner
    </a>{' '}
    for den fullstendige listen, endringspolicyen og feilsøking.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Skriv inn legitimasjonen i Living Security Platform">
    <p>
      Utføres av den som har tilgang til Living Security – programeieren, eller systemadministratoren
      dersom vedkommende er invitert (delegert oppsett).
    </p>
    <ol>
      <li>
        Gå til <strong>Innstillinger → Integrasjoner → Catalog</strong>, finn flisen{' '}
        <strong>{tile}</strong>, og klikk på <strong>Koble til</strong>.
      </li>
      <li>
        Fyll ut feltene nedenfor, og klikk deretter på <strong>Koble til</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Oversikt

Okta kan bidra med normalisert aktivitet knyttet til brukerlivssyklus, autentisering, MFA og administrasjon. Gjennomgåtte eksempler omfatter:

* `account.locked` — konto låst
* `mfa.factor.activated` — aktiverer flere MFA-faktorer
* `auth.login.failed` — mislykket pålogging

Begge tilkoblingsmetodene leser de samme to strømmene — brukerkatalogen (`/api/v1/users`) og systemloggen (`/api/v1/logs`). Se [hvordan integrasjonsdata blir til signaler](/no/signals/data-sources).

## Velg en tilkoblingsmetode

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Legitimasjon | Et API-token du oppretter i Admin Console | En klient-ID og en privat JWK som du genererer og registrerer |
| Oppsett | Tre trinn, ingen nøkkelmateriale å generere | Ni trinn, inkludert et RSA-nøkkelpar |
| Påkrevd administratorrolle | Skrivebeskyttet administrator, tildelt tokenets eier | Skrivebeskyttet administrator, tildelt applikasjonen |
| Levetid for token | Deaktiveres etter 30 dager uten bruk | Ingen utløpsdato; nøkkelparet må du rotere selv |
| Bruk den når | Dette er den anbefalte løsningen for de fleste organisasjoner | Sikkerhetspolicyen deres forbyr langlivede API-tokens |

Begge metodene krever samme tilgang, så valget handler om håndtering av legitimasjon, ikke om hva plattformen kan lese.

***

## Alternativ A — API-token (SSWS)

*Anbefalt.*

### Hva Living Security trenger

| Legitimasjon | Beskrivelse |
| - | - |
| **API-nøkkel** | Et Okta API-token. Tilkoblingsdialogen kaller dette feltet **API-nøkkel** |
| **Tenant subdomain** | `<tenant>` i `<tenant>.okta.com` — kun selve subdomenet, ikke hele URL-en |

### Forutsetninger

* Du må være **Super Administrator** i Okta for å opprette en tjenestekontobruker, tildele administratorroller og opprette API-tokens.

<Steps>
  <Step title="Opprett en bruker som skal eie tokenet">
    Et Okta API-token har de samme tillatelsene som brukeren som opprettet det, og det slutter å fungere hvis brukeren deaktiveres. Opprett en dedikert tjenestekonto i stedet for å bruke en personlig administratorkonto, slik at tilkoblingen overlever endringer i staben.

    1. Gå til **Directory** → **People** i Admin Console.
    2. Klikk på **Add person** og opprett en bruker, for eksempel `svc-livingsecurity@yourcompany.com`.
    3. Aktiver kontoen.
  </Step>

  <Step title="Tildel rollen som skrivebeskyttet administrator">
    Plattformen leser kun data. Hvis du gir mer enn lesetilgang, får tokenet tillatelser det aldri bruker.

    1. Gå til **Security** → **Administrators**.
    2. Klikk på **Add administrator** og velg brukeren fra forrige trinn.
    3. Tildel rollen **Read-only Administrator**.
    4. Lagre.

    <Note>
      Uten en administratorrolle lykkes kall til Okta Management API med `200 OK` og returnerer en tom liste. Det finnes ingen `403` som forteller at rollen mangler — strømmene forblir bare tomme.
    </Note>
  </Step>

  <Step title="Opprett API-tokenet">
    1. Logg inn i Admin Console **som tjenestekontobrukeren** fra trinn 1. Tokenet arver tillatelsene til kontoen som oppretter det.
    2. Gå til **Security** → **API** og åpne fanen **Tokens**.
    3. Klikk på **Create token**, gi det et navn, for eksempel `Living Security Platform`, og klikk på **Create token**.
    4. Kopier tokenverdien nå — Okta viser den bare én gang.

    <Warning>
      Okta deaktiverer et API-token etter **30 dager uten bruk**. Synkroniseringene i denne integrasjonen kjøres minst én gang per dag, så en aktiv tilkobling holder sitt eget token i live. En tilkobling som står på pause i en måned, trenger et nytt token.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Adresselisten ovenfor er bare relevant hvis Okta-organisasjonen deres begrenser API-tilgang med **nettverkssoner**. De fleste organisasjoner gjør ikke det.
    </Note>
  </Step>

  <Step title="Finn tenantens subdomene">
    URL-en til Admin Console ser ut som `https://acme-admin.okta.com`. Tenantens subdomene er `acme` — uten suffikset `-admin`, uten `.okta.com` og uten `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Felt | Verdi |
    | - | - |
    | **API-nøkkel** | API-tokenet fra trinn 3 |
    | **Tenant subdomain** | Subdomenet fra trinn 4 (f.eks. `acme`) |
  </ConnectInPlatform>
</Steps>

Du er nå koblet til Okta (SSWS).

### Feilsøking

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Tokenet er ugyldig, har blitt tilbakekalt eller har blitt deaktivert etter 30 dagers inaktivitet. Opprett et nytt token som tjenestekontobrukeren, og skriv det inn på nytt i tilkoblingen.
  </Accordion>

  <Accordion title="Tilkoblet, men alle strømmer er tomme">
    Tokenets eier har ingen administratorrolle. Tildel **Read-only Administrator** til tjenestekontoen (trinn 2) — API-et returnerer `200 OK` med en tom liste i stedet for en feil når rollen mangler.
  </Accordion>

  <Accordion title="Synkroniseringer mislykkes etter en endring i staben">
    Tokenet slutter å fungere hvis brukeren som opprettet det, deaktiveres. Derfor bør tokenet tilhøre en tjenestekonto og ikke en person.
  </Accordion>
</AccordionGroup>

***

## Alternativ B — OAuth 2.0-tjenesteapplikasjon

Bruk denne metoden hvis sikkerhetspolicyen deres ikke tillater langlivede API-tokens. Den erstatter tokenet med en klient-ID og et RSA-nøkkelpar som dere selv eier. I plattformen er dette flisen **Okta (OAuth 2.0)** under **Innstillinger → Integrasjoner → Catalog**.

For å autentisere mot Okta med Client Credentials trenger du følgende:

1. **klient-ID** - En unik identifikator for Okta API Services-applikasjonen din.
2. **Private Key (JWK)** - Den private RSA-nøkkelen i JSON Web Key-format, hvis offentlige nøkkel er registrert i Okta-applikasjonen din.
3. **Okta Domain** - Kun subdomenet til Okta-tenanten din (f.eks. `dev-12345678`), ikke hele vertsnavnet.
4. **Scopes** - En mellomromseparert liste over scopes for Okta Management API (f.eks. `okta.users.read okta.logs.read`).

Denne veiledningen viser hvordan du oppretter en API Services-applikasjon i Okta med `private_key_jwt`-autentisering.

### Forutsetninger:

* Du må ha en Okta-konto. Registrer en gratis utviklerkonto på [developer.okta.com](https://developer.okta.com/signup/).

#### Trinn 1: Opprette Okta API Services-applikasjonen

1. Logg inn på [Okta Admin Console](https://login.okta.com/).
2. Gå til **Applications** > **Applications** i sidemenyen til venstre.
3. Klikk på **Create App Integration**.
4. Velg **API Services** som påloggingsmetode og klikk på **Neste**.

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

5. Gi applikasjonen et navn og klikk på **Lagre**.
6. Finn **klient-ID** på fanen **General** i applikasjonen — du trenger den i det siste trinnet.
7. Sett Client authentication til **Public key / Private key**. `okta.*`-scopes støttes bare med denne autentiseringsmetoden.

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

8. Deaktiver **Proof of possession (DPoP)** — det støttes ikke.

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

<Note>
  Applikasjonen må opprettes som **API Services**.
</Note>

#### Trinn 2: Generere og registrere RSA-nøkkelparet

##### Bruk Oktas nøkkelgenerator

Okta kan generere RSA-nøkkelparet for deg direkte i Admin Console:

1. Åpne API Services-applikasjonen din i Admin Console.
2. Gå til fanen **General** og bla til delen **PUBLIC KEYS**.
3. Klikk på **Add Key**, og velg deretter **Generate new key**.
4. Klikk på **Lagre** — Okta genererer nøkkelparet og viser **Private Key (JWK)** én gang.
5. Kopier og lagre den private nøkkelen i JSON-format med en gang — den vises ikke igjen.

<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økkelen registreres automatisk i applikasjonen din.

<Note>
  Kopier den private JWK-en før du lukker dialogen. Lim den inn i feltet **Private Key** i Living Security Platform i det siste trinnet.
</Note>

##### Lag din egen nøkkel

Okta bruker `private_key_jwt` for API Services-apper. Du genererer et RSA-nøkkelpar, registrerer den **offentlige** JWK-en i Okta og oppgir den **private** JWK-en til Living Security Platform.

**Generer en privat JWK** ved hjelp av følgende Node.js-skript (krever 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));
```

**Registrer den offentlige JWK-en i Okta:**

1. Åpne API Services-applikasjonen din i Admin Console.
2. Gå til fanen **General** og bla til delen **PUBLIC KEYS**.
3. Klikk på **Add Key**, lim inn JSON-utdataene for den **offentlige JWK-en** fra skriptet ovenfor, og klikk på **Lagre**.

<Note>
  Den private JWK-en er den du limer inn i Living Security Platform. Den inneholder alt nøkkelmateriale (`d`, `p`, `q`, `dp`, `dq`, `qi`) og `kid`. Hold den hemmelig.
</Note>

#### Trinn 3: Finne Okta Domain

Oppgi kun subdomenet til Okta-tenanten din — delen før `.okta.com`.

* I Admin Console viser nettleserens adresselinje en URL som `https://dev-12345678-admin.okta.com`.
* **Okta Domain** er kun subdomenet (f.eks. `dev-12345678`), ikke `dev-12345678.okta.com`.
* Alternativt kan du gå til **Innstillinger** > **Account** i Admin Console for å finne Okta-domenet ditt, og deretter bruke subdomenedelen.

#### Trinn 4: Gi API-scopes til applikasjonen din

Okta krever minst ett scope i hver tokenforespørsel. Før applikasjonen din kan be om bestemte scopes, må de innvilges:

1. Gå til **Applications** > **Applications** i Admin Console, og åpne applikasjonen din.
2. Klikk på fanen **Okta API Scopes**.
3. Innvilg scopene integrasjonen din trenger: `okta.users.read` og `okta.logs.read`.

En fullstendig liste over tilgjengelige scopes finnes i [Okta Management API-referansen](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Trinn 5: Tildel en administratorrolle til applikasjonen din

Det er ikke nok å innvilge scopes — endepunkter i Okta Management API (f.eks. `/api/v1/users`) returnerer stille et tomt `200 []`-svar hvis applikasjonen din ikke har en administratorrolle. Du må tildele minst **Read-Only Administrator**:

1. Gå til **Sikkerhet** > **Administrators** i Admin Console (eller gå til **Applications** > **Applications** > appen din > **Admin roles**).
2. Klikk på **Add administrator assignment** og velg API Services-applikasjonen din.

<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øyere, avhengig av hvilke scopes du trenger).
4. Klikk på **Lagre**.

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

<Note>
  Uten en administratorrolle lykkes API-kall med `200 OK`, men returnerer tomme resultater, og det finnes ingen `403`-feil som indikerer problemet.
</Note>

#### Trinn 6: Skriv inn legitimasjonen i Living Security Platform

Når du har **klient-ID**, **Private Key (JWK)**, **Okta Domain** og **Scopes**:

1. Åpne skjemaet der du skal autentisere mot Okta (Client Credentials).
2. Skriv inn **klient-ID**.
3. Lim inn **Private Key (JWK)** — hele JSON-objektet fra skriptet ovenfor (på én linje eller formatert).
4. Skriv inn **Okta Domain** som kun tenantens subdomene (f.eks. `dev-12345678`).
5. Skriv inn **Scopes** som en mellomromseparert liste (f.eks. `okta.users.read okta.logs.read`).
6. Send inn skjemaet, så skal du være autentisert.

Du er nå koblet til Okta (Client Credentials).

***

<Note>Deler av denne dokumentasjonen er tilpasset fra [Nango](https://nango.dev/docs/) og brukes i henhold til [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.