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

# OAuth-klientlegitimasjon

> Opprett en klient med begrenset omfang for en tjenestekonto, håndter hemmeligheter som kun vises én gang, og gjenopprett trygt etter usikre forespørsler.

Bruk OAuth-klientlegitimasjon når backend-integrasjonen din trenger kortlevde
tilgangstokener, eller når sikkerhetspolicyen din krever det. Hver klient tilhører
én tjenestekonto og én organisasjon. **OAuth er valgfritt:** en API-nøkkel med
begrenset omfang er tilstrekkelig for en privat serverintegrasjon som kan lagre
og rotere en nøkkel på en sikker måte. Se [Autentisering](/no/developers/v1/authentication) for å velge
mellom de to metodene og for å forstå hvordan tjenestekontoer passer inn.

<Note>
  OAuth-tilgang må være aktivert for organisasjonen din. Oppsettet ditt gir
  det regionale token-endepunktet, utstederen (issuer), målgruppen (audience) og metoden for klientautentisering.
  Hvis du trenger disse innstillingene eller ikke har tilgang til klientadministrasjon, kan du kontakte
  Living Security Support.
</Note>

Tildelingen av klientlegitimasjon (client credentials grant) representerer tjenestekontoen din. Den logger ikke inn en person
og ber ikke en kunde om å autorisere et program. Delegert autorisasjon via
nettleser er en separat OAuth-funksjon og tilbys ikke av disse operasjonene.

## Før du begynner

* Opprett en [tjenestekonto](/no/developers/developer-hub/service-accounts) med kun
  de tillatelsene integrasjonen trenger.
* Bruk en administrasjonslegitimasjon med `service_account:manage` og hver tillatelse
  du vil gi til den nye klienten. Målkontoen må også ha disse
  tillatelsene. En klient kan ikke utvide noen av kontoenes myndighet.
* Velg organisasjonens [region](/no/developers/v1/regions). API-legitimasjon og
  OAuth-tilgangstokener hører hjemme på den tilsvarende regionale API-verten.
* Oppbevar klienthemmeligheten og tokenene i hemmelighetslagringen på serversiden. Legg dem aldri
  i nettleserkode, mobilapplikasjoner, kildekontroll eller forespørselslogger.

## Opprett en klient

`POST /v1/oauth_clients` krever `service_account_id`, en ikke-tom liste med eksplisitte
`scopes` og en `Idempotency-Key`. Jokertegn godtas ikke. En klient støtter
opptil 100 omfang (scopes), med en samlet lengde på høyst 4 096 tegn. Hver tjenestekonto
kan ha høyst 20 klienter eller uløste opprettings-/oppryddingsoperasjoner.
Tilbakekalling nekter umiddelbart API-tilgang. En klient eller en usikker opprettelse hos leverandøren
fortsetter å telle mot grensen helt til ekstern opprydding er bekreftet.
En forlatt reservasjon eller en opprettelse som er bevist å ha feilet før arbeid hos leverandøren
startet, kan frigi plassen sin på en trygg måte. Gjentakelsesnøkkelen tilhører fortsatt det opprinnelige
forsøket; gjenopprett den kvitteringen før du bestemmer deg for å opprette en erstatning.

Velg én gjentakelsesnøkkel (retry key) for dette opprettingsforsøket, og lagre den varig **før** du sender
forespørselen. Bruk 1–255 synlige ASCII-tegn, uten mellomrom. Gjenbruk den med
samme konto, omfang, administrasjonsprinsipal, region og API-versjon etter et tapt
svar. Rotasjon av administrasjonslegitimasjonen under samme tjenestekonto
oppretter ikke en ny gjentakelsesidentitet.

Installer Python-pakken `requests`. Last inn følgende miljøverdier gjennom
din vanlige hemmelighets- og konfigurasjonshåndtering:

| Variabel | Verdi |
| - | - |
| `LIVING_SECURITY_API_KEY` | Administrasjons-API-nøkkel |
| `LIVING_SECURITY_REGION` | `us` eller `eu` |
| `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | ID for målets tjenestekonto |
| `LIVING_SECURITY_OAUTH_CREATE_KEY` | Tidligere lagret gjentakelsesnøkkel |

```python Python theme={null}
import os
import requests

HOSTS = {
    "us": "https://api.us-east-1.livingsecurity.ai/v1",
    "eu": "https://api.eu-west-1.livingsecurity.ai/v1",
}
base = HOSTS[os.environ["LIVING_SECURITY_REGION"]]
response = requests.post(
    f"{base}/oauth_clients",
    auth=("apikey", os.environ["LIVING_SECURITY_API_KEY"]),
    headers={
        "Living-Security-Version": "2026-07-01",
        "Idempotency-Key": os.environ["LIVING_SECURITY_OAUTH_CREATE_KEY"],
    },
    json={
        "service_account_id": os.environ["LIVING_SECURITY_SERVICE_ACCOUNT_ID"],
        "scopes": ["organization:read"],
    },
    timeout=(5, 30),
    allow_redirects=False,
)
try:
    if response.status_code != 201:
        raise RuntimeError(
            f"Client creation needs review: HTTP {response.status_code}; "
            f"request_id={response.headers.get('Request-Id', 'unknown')}"
        )
    client = response.json()
    if client.get("object") != "oauth_client" or not client.get("id"):
        raise RuntimeError("Unexpected client receipt; preserve the retry key")
    if client.get("status") != "active" or not client.get("client_secret"):
        raise RuntimeError(
            f"Client {client['id']} needs recovery; no usable secret was returned"
        )
    # Persist client['id'], client['client_id'], and client['client_secret']
    # directly in your secret manager before using the client. Do not print them.
finally:
    response.close()
```

Eksempelet sender én forespørsel og beholder resultatet i minnet. Legg til skriveoperasjonen
til hemmelighetsbehandleren din på det markerte punktet før du kjører det i produksjon.
Det krever bevisst en beslutning etter et usikkert resultat i stedet for stille å
opprette en ny klient. Nettverksunntak krever også gjenopprettingstrinnene nedenfor.

Svar på oppretting og kvittering bruker `201` og inneholder en `oauth_client`-ressurs
med `id`, `service_account_id`, `client_id`, `scopes`, `status`, `created_at` og
`client_secret`. Svarene er merket `Cache-Control: no-store`.

* **`id`** identifiserer plattformressursen. Lagre den for henting og tilbakekalling.
* **`client_id`** identifiserer klienten under tokenutveksling. Det er ikke
  plattformens ressurs-ID. Den kan være `null` mens oppretting venter.
* **`client_secret`** returneres kun til forespørselen som fullfører opprettingen.
  Hver gjentatte opprettingsforespørsel returnerer `null`, også et nytt forsøk etter et tapt
  suksessvar. Henting returnerer aldri en hemmelighet.

## Gjenopprett etter et tapt eller avbrutt svar

Gjenta den samme opprettingsforespørselen med den lagrede gjentakelsesnøkkelen for å gjenopprette en
ressurskvittering. Kvitteringen gjenspeiler gjeldende tilstand, slik at en tilbakekalt klient forblir tilbakekalt.
Denne operasjonen bruker ikke den generelle avspillingskontrakten for bufrede svar på 24 timer
og returnerer ikke en `Idempotent-Replayed`-header.

| Resultat | Neste handling |
| - | - |
| `active`, hemmelighet til stede | Lagre hemmeligheten sikkert og fortsett onboardingen. |
| `active`, hemmelighet mangler | Hemmeligheten kan ikke gjenopprettes. Tilbakekall denne klienten, bekreft tilbakekallingen, og opprett deretter en erstatning med en ny gjentakelsesnøkkel. |
| `pending` | Opprettingen er ikke bekreftet. Behold den samme gjentakelsesnøkkelen. Hent ressursen for å undersøke tilstanden; ikke opprett duplikater for å omgå usikkerheten. |
| `revoked`, `disabled` eller `expired` | Ikke bruk denne klienten. Bekreft den tiltenkte kontokonfigurasjonen før du oppretter en erstatning. |
| `409 idempotency_key_reuse` | Forespørselen ble endret under en eksisterende nøkkel. Gjenopprett den opprinnelige operasjonen før du avgjør om en separat opprettelse er nødvendig. |
| `409 invalid_request` | Kontroller målkontoens status og tildelinger. Hvis klientgrensen ble nådd, må du fullføre oppryddingen før du prøver på nytt; å endre gjentakelsesnøkkelen frigjør ikke kapasitet. |
| `429` | Følg `Retry-After`; behold den samme nøkkelen og forespørselen. |
| `500`, `503` eller en nettverkstidsavbrudd | Utfallet kan være ukjent. Bevar nøkkelen og inndataene; gjenopprett kvitteringen før du oppretter en ny klient. |
| `401` eller `403` | Løs problemer med tilgang til legitimasjon, tillatelser eller rettigheter før du prøver på nytt. |
| `404` | Bekreft OAuth-aktivering, regional vert og eierskap til ressursen. |

Se [feil](/no/developers/v1/errors/overview) for forespørsels-ID-er og detaljer om gjenoppretting.
Send aldri en klienthemmelighet eller et tilgangstoken sammen med en støtteforespørsel.

## Inspiser og tilbakekall

Bruk administrasjonslegitimasjonen din og plattformressursen `id`:

| Operasjon | Forespørsel | Vellykket |
| - | - | - |
| Inspiser gjeldende tilstand | `GET /v1/oauth_clients/{id}` | `200`, klientressurs uten hemmelighet |
| Tilbakekall tilgang | `DELETE /v1/oauth_clients/{id}` | `200`, tilbakekalt klientressurs uten hemmelighet |

Tilbakekalling blokkerer påfølgende API-forespørsler for klienten, inkludert forespørsler med
tokener som allerede er utstedt. Den avbryter ikke arbeid som API-et allerede har akseptert.
Ekstern opprydding av legitimasjon kan fullføres senere. Det er trygt å gjenta tilbakekallingen, og den
krever ingen gjentakelsesnøkkel. Fortsett å bruke administrasjonslegitimasjonen hvis klienten
som tilbakekalles selv er en API-kaller.

## Roter uten å miste tilgang

Opprett en ny klient med det nødvendige omfangstaket. Lagre hemmeligheten, hent et
token via det regionale token-endepunktet ditt, og kontroller at integrasjonen fungerer
med det. Bytt integrasjonen over til erstatningen, og tilbakekall deretter den gamle ressursen.
Behold en uavhengig administrasjonslegitimasjon slik at du kan gjenopprette etter en mislykket utrulling.

Tilgangstokener kan ikke gi mer enn klientens omfang og tjenestekontoens
gjeldende tillatelser. Fjerning av kontotillatelser eller tilbakekalling av en klient har
forrang over et tokens gjenværende levetid. Ikke anta at et bufret token beviser
at autorisasjonen fortsatt er gyldig. Hent et nytt tilgangstoken før utløp ved å
autentisere klienten på nytt; denne tildelingen bruker ikke oppdateringstokener (refresh tokens).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.