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

# Konfigurering av Okta-integration

> Anslut Okta till Living Security för användarlivscykel, autentisering, MFA och administrativ aktivitet.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>Relaterade resurser</h2>
    <ul>
      <li>
        <a href="/sv/signals/data-sources">Läs hur data från integrationer blir signaler för Human Risk Management</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Utforska Living Securitys integrationer</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Öppna Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Begär en demo av Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Lägg till alla fyra utgående IP-adresser för synkronisering från Living Security</strong> i tillåtelselistan i{' '}
    {system}. Ange varje adress som en enskild värd med <code>/32</code> om {system} förväntar sig 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 />
    Trafiken kan komma från vilken som helst av de fyra adresserna, så om endast några av dem tillåtslistas uppstår återkommande
    synkroniseringsfel. Dessa fyra adresser är desamma i alla regioner för Living Security. Se{' '}
    <a href="/sv/integrations/managing/egress-ip-addresses">
      Konfigurera utgående IP-adresser för Integrationer
    </a>{' '}
    för den fullständiga listan, policyn för ändringar och felsökning.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Ange autentiseringsuppgifterna i Living Security Platform">
    <p>
      Utförs av den som har åtkomst till Living Security – programägaren, eller
      systemadministratören om denne har blivit inbjuden (delegerad konfiguration).
    </p>
    <ol>
      <li>
        Gå till <strong>Inställningar → Integrationer → Katalog</strong>, leta upp panelen{' '}
        <strong>{tile}</strong> och klicka på <strong>Anslut</strong>.
      </li>
      <li>
        Fyll i fälten nedan och klicka sedan på <strong>Anslut</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## Översikt

Okta kan bidra med normaliserad data om användarlivscykel, autentisering, MFA och administrativ aktivitet. Granskade exempel omfattar:

* `account.locked` — kontot är låst
* `mfa.factor.activated` — aktiverar ytterligare MFA-faktorer
* `auth.login.failed` — misslyckas med att logga in

Båda anslutningsmetoderna läser samma två flöden — användarkatalogen (`/api/v1/users`) och systemloggen (`/api/v1/logs`). Se [hur integrationsdata blir signaler](/sv/signals/data-sources).

## Välj anslutningsmetod

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Autentiseringsuppgift | En API-token som du skapar i Admin Console | Ett klient-ID och en privat JWK som du genererar och registrerar |
| Konfigurering | Tre steg, inget nyckelmaterial att generera | Nio steg, inklusive ett RSA-nyckelpar |
| Administratörsroll som krävs | Skrivskyddad administratör, tilldelad tokenägaren | Skrivskyddad administratör, tilldelad applikationen |
| Tokens livslängd | Inaktiveras efter 30 dagar utan användning | Ingen utgång; nyckelparet roterar du själv |
| Använd den när | Detta är den rekommenderade vägen för de flesta organisationer | Er säkerhetspolicy förbjuder långlivade API-token |

Båda metoderna kräver samma åtkomst, så valet handlar om hur autentiseringsuppgifter hanteras, inte om vad plattformen kan läsa.

***

## Alternativ A — API-token (SSWS)

*Rekommenderas.*

### Vad Living Security behöver

| Autentiseringsuppgift | Beskrivning |
| - | - |
| **API-nyckel** | En Okta API-token. Anslutningsdialogen kallar det här fältet **API-nyckel** |
| **Klientens underdomän** | `<tenant>` i `<tenant>.okta.com` — enbart underdomänen, inte hela URL:en |

### Förutsättningar

* Du måste vara **Super Administrator** i Okta för att kunna skapa en tjänstekontoanvändare, tilldela administratörsroller och skapa API-token.

<Steps>
  <Step title="Skapa en användare som äger token">
    En Okta API-token har samma behörigheter som den användare som skapade den, och den slutar fungera om användaren inaktiveras. Skapa ett dedikerat tjänstekonto i stället för att använda ett personligt administratörskonto, så att anslutningen består när personalen byts ut.

    1. Gå till **Directory** → **People** i Admin Console.
    2. Klicka på **Add person** och skapa en användare, till exempel `svc-livingsecurity@yourcompany.com`.
    3. Aktivera kontot.
  </Step>

  <Step title="Tilldela den skrivskyddade administratörsrollen">
    Plattformen läser endast. Om du ger mer än läsbehörighet får token behörigheter som den aldrig använder.

    1. Gå till **Säkerhet** → **Administrators**.
    2. Klicka på **Add administrator** och välj användaren från föregående steg.
    3. Tilldela rollen **Read-only Administrator**.
    4. Spara.

    <Note>
      Utan en administratörsroll lyckas anrop till Okta Management API med `200 OK` och returnerar en tom lista. Det finns inget `403` som talar om att rollen saknas — flödena förblir helt enkelt tomma.
    </Note>
  </Step>

  <Step title="Skapa API-token">
    1. Logga in i Admin Console **som tjänstekontoanvändaren** från steg 1. Token ärver behörigheterna från det konto som skapar den.
    2. Gå till **Säkerhet** → **API** och öppna fliken **Tokens**.
    3. Klicka på **Create token**, ge den ett namn som `Living Security Platform` och klicka på **Create token**.
    4. Kopiera tokenvärdet nu — Okta visar det bara en gång.

    <Warning>
      Okta inaktiverar en API-token efter **30 dagar utan användning**. Synkroniseringarna i den här integrationen körs minst en gång per dag, så en aktiv anslutning håller sin egen token vid liv. En anslutning som lämnas pausad i en månad behöver en ny token.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Adresslistan ovan är endast relevant om din Okta-organisation begränsar API-åtkomst via **nätverkszon**. Det gör de flesta organisationer inte.
    </Note>
  </Step>

  <Step title="Hitta din klientunderdomän">
    Din URL till Admin Console ser ut som `https://acme-admin.okta.com`. Klientens underdomän är `acme` — utan suffixet `-admin`, utan `.okta.com` och utan `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Fält | Värde |
    | - | - |
    | **API-nyckel** | API-token från steg 3 |
    | **Klientens underdomän** | Underdomänen från steg 4 (t.ex. `acme`) |
  </ConnectInPlatform>
</Steps>

Du är nu ansluten till Okta (SSWS).

### Felsökning

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Token är ogiltig, har återkallats eller har inaktiverats efter 30 dagars inaktivitet. Skapa en ny token som tjänstekontoanvändaren och ange den på nytt i anslutningen.
  </Accordion>

  <Accordion title="Ansluten, men alla flöden är tomma">
    Tokenägaren har ingen administratörsroll. Tilldela **Read-only Administrator** till tjänstekontot (steg 2) — API:et returnerar `200 OK` med en tom lista i stället för ett fel när rollen saknas.
  </Accordion>

  <Accordion title="Synkroniseringar misslyckas efter personalförändring">
    Token slutar fungera om användaren som skapade den inaktiveras. Därför bör token tillhöra ett tjänstekonto och inte en person.
  </Accordion>
</AccordionGroup>

***

## Alternativ B — OAuth 2.0-tjänsteapplikation

Använd den här metoden när er säkerhetspolicy inte tillåter långlivade API-token. Den ersätter token med ett klient-ID och ett RSA-nyckelpar som du äger. I plattformen är detta panelen **Okta (OAuth 2.0)** under **Inställningar → Integrationer → Katalog**.

För att autentisera mot Okta med Client Credentials behöver du följande:

1. **Klient-ID** - En unik identifierare för din Okta API Services-applikation.
2. **Privat nyckel (JWK)** - Den privata RSA-nyckeln i JSON Web Key-format, vars publika nyckel är registrerad i din Okta-applikation.
3. **Okta-domän** - Enbart din Okta-klientunderdomän (t.ex. `dev-12345678`), inte hela värdnamnet.
4. **Scopes** - En blankstegsseparerad lista med Okta Management API-scopes (t.ex. `okta.users.read okta.logs.read`).

Den här guiden går igenom hur du skapar en API Services-applikation i Okta med autentiseringen `private_key_jwt`.

### Förutsättningar:

* Du måste ha ett Okta-konto. Registrera ett kostnadsfritt utvecklarkonto på [developer.okta.com](https://developer.okta.com/signup/).

#### Steg 1: Skapa din Okta API Services-applikation

1. Logga in på din [Okta Admin Console](https://login.okta.com/).
2. Navigera till **Applications** > **Applications** i det vänstra sidofältet.
3. Klicka på **Create App Integration**.
4. Välj **API Services** som inloggningsmetod och klicka på **Nästa**.

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

5. Ge din applikation ett namn och klicka på **Spara**.
6. Hitta ditt **klient-ID** på applikationens flik **General** — du behöver det i det sista steget.
7. Ställ in Client authentication på **Public key / Private key**. `okta.*`-scopes stöds endast med den här autentiseringsmetoden.

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

8. Inaktivera **Proof of possession (DPoP)** — det stöds inte.

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

<Note>
  Applikationen måste skapas som **API Services**.
</Note>

#### Steg 2: Generera och registrera ditt RSA-nyckelpar

##### Använd Oktas nyckelgenerator

Okta kan generera RSA-nyckelparet åt dig direkt i Admin Console:

1. Öppna din API Services-applikation i Admin Console.
2. Gå till fliken **General** och rulla till avsnittet **PUBLIC KEYS**.
3. Klicka på **Add Key** och välj sedan **Generate new key**.
4. Klicka på **Spara** — Okta genererar nyckelparet och visar den **privata nyckeln (JWK)** en enda gång.
5. Kopiera och spara den privata nyckelns JSON omedelbart — den visas inte igen.

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

6. Den publika nyckeln registreras automatiskt för din applikation.

<Note>
  Kopiera den privata JWK:n innan du stänger dialogrutan. Klistra in den i fältet **Privat nyckel** i Living Security Platform i det sista steget.
</Note>

##### Skapa din egen nyckel

Okta använder `private_key_jwt` för API Services-appar. Du genererar ett RSA-nyckelpar, registrerar den **publika** JWK:n hos Okta och anger den **privata** JWK:n till Living Security Platform.

**Generera en privat JWK** med följande Node.js-skript (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));
```

**Registrera den publika JWK:n i Okta:**

1. Öppna din API Services-applikation i Admin Console.
2. Gå till fliken **General** och rulla till avsnittet **PUBLIC KEYS**.
3. Klicka på **Add Key**, klistra in den **publika JWK-JSON:en** från skriptets utdata ovan och klicka på **Spara**.

<Note>
  Den privata JWK:n är den du klistrar in i Living Security Platform. Den innehåller allt nyckelmaterial (`d`, `p`, `q`, `dp`, `dq`, `qi`) samt `kid`. Håll den hemlig.
</Note>

#### Steg 3: Hitta din Okta-domän

Ange enbart din Okta-klientunderdomän — delen före `.okta.com`.

* I Admin Console visar webbläsarens adressfält en URL som `https://dev-12345678-admin.okta.com`.
* Din **Okta-domän** är enbart underdomänen (t.ex. `dev-12345678`), inte `dev-12345678.okta.com`.
* Du kan också gå till **Inställningar** > **Account** i Admin Console för att hitta din Okta-domän och sedan använda underdomändelen.

#### Steg 4: Bevilja API-scopes till din applikation

Okta kräver minst ett scope i varje tokenbegäran. Innan din applikation kan begära specifika scopes måste de beviljas:

1. Navigera till **Applications** > **Applications** i Admin Console och öppna din applikation.
2. Klicka på fliken **Okta API Scopes**.
3. Bevilja de scopes som din integration kräver: `okta.users.read` och `okta.logs.read`.

En fullständig lista över tillgängliga scopes finns i [Okta Management API-referensen](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### Steg 5: Tilldela en administratörsroll till din applikation

Enbart beviljade scopes räcker inte — slutpunkter i Okta Management API (t.ex. `/api/v1/users`) returnerar tyst ett tomt `200 []`-svar om din applikation saknar administratörsroll. Du måste tilldela minst **Read-Only Administrator**:

1. Navigera till **Säkerhet** > **Administrators** i Admin Console (eller gå till **Applications** > **Applications** > din app > **Admin roles**).
2. Klicka på **Add administrator assignment** och välj 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. Tilldela rollen **Read-Only Administrator** (eller högre, beroende på vilka scopes du behöver).
4. Klicka på **Spara**.

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

<Note>
  Utan en administratörsroll lyckas API-anrop med `200 OK` men returnerar tomma resultat, och det finns inget `403`-fel som indikerar problemet.
</Note>

#### Steg 6: Ange autentiseringsuppgifter i Living Security Platform

När du har ditt **klient-ID**, din **privata nyckel (JWK)**, din **Okta-domän** och dina **scopes**:

1. Öppna formuläret där du behöver autentisera mot Okta (Client Credentials).
2. Ange ditt **klient-ID**.
3. Klistra in din **privata nyckel (JWK)** — hela JSON-objektet från skriptet ovan (på en rad eller formaterat).
4. Ange din **Okta-domän** som enbart klientunderdomänen (t.ex. `dev-12345678`).
5. Ange **scopes** som en blankstegsseparerad lista (t.ex. `okta.users.read okta.logs.read`).
6. Skicka formuläret, så ska du vara autentiserad.

Du är nu ansluten till Okta (Client Credentials).

***

<Note>Delar av den här dokumentationen är anpassade från [Nango](https://nango.dev/docs/) och används 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.