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

> Opret en afgrænset servicekontoklient, håndter engangshemmeligheder, og genopret sikkert efter usikre anmodninger.

Brug OAuth-klientlegitimationsoplysninger, når din backend-integration har brug for kortvarige
adgangstokens, eller når din sikkerhedspolitik kræver dem. Hver klient tilhører
én servicekonto og én organisation. **OAuth er valgfrit:** en afgrænset
API-nøgle er tilstrækkelig til en privat serverintegration, der kan opbevare og
rotere en nøgle sikkert. Se [Godkendelse](/da/developers/v1/authentication) for at vælge
mellem de to metoder og forstå, hvordan servicekonti indgår.

<Note>
  OAuth-adgang skal være aktiveret for din organisation. Din opsætning angiver
  det regionale tokenendepunkt, udstederen, målgruppen (audience) og klientgodkendelsesmetoden.
  Hvis du har brug for disse indstillinger, eller hvis du ikke kan få adgang til klientadministration, skal du kontakte
  Living Security Support.
</Note>

Grant-typen med klientlegitimationsoplysninger repræsenterer din servicekonto. Den logger ikke en person ind
og beder ikke en kunde om at godkende et program. Delegeret godkendelse via en
browser er en separat OAuth-funktion og tilbydes ikke af disse operationer.

## Inden du begynder

* Opret en [servicekonto](/da/developers/developer-hub/service-accounts) med kun
  de tilladelser, som integrationen har brug for.
* Brug en administrationslegitimation med `service_account:manage` og hver tilladelse,
  du vil give til den nye klient. Målkontoen skal også have disse
  tilladelser. En klient kan ikke udvide nogen af kontoenes beføjelser.
* Vælg organisationens [region](/da/developers/v1/regions). API-legitimationsoplysninger og
  OAuth-adgangstokens hører til på den tilsvarende regionale API-vært.
* Opbevar klienthemmeligheden og tokens i din serverside-hemmelighedslagring. Placer dem aldrig
  i browserkode, mobilapplikationer, kildekodestyring eller anmodningslogfiler.

## Opret en klient

`POST /v1/oauth_clients` kræver `service_account_id`, en ikke-tom liste med eksplicitte
`scopes` og en `Idempotency-Key`. Jokertegn accepteres ikke. En klient understøtter
op til 100 scopes med en samlet længde på højst 4.096 tegn. Hver serviceserviceskonto
kan højst have 20 klienter eller uafklarede oprettelses-/oprydningsoperationer.
Tilbagekaldelse afviser straks API-adgang. En klient eller en usikker oprettelse hos udbyderen
tæller fortsat med i grænsen, indtil den eksterne oprydning er bekræftet.
En opgivet reservation eller en oprettelse, der beviseligt mislykkedes, før udbyderens arbejde
begyndte, kan frigive sin plads sikkert. Dens genforsøgsnøgle tilhører stadig det oprindelige
forsøg; genopret den pågældende kvittering, før du beslutter, om du vil oprette en erstatning.

Vælg én genforsøgsnøgle til dette oprettelsesforsøg, og gem den **før** du sender
anmodningen. Brug 1–255 synlige ASCII-tegn uden mellemrum. Genbrug den med den
samme konto, de samme scopes, den samme administrationsprincipal, region og API-version efter et tabt
svar. Rotation af administrationslegitimationen under den samme serviceskonto
opretter ikke en ny genforsøgsidentitet.

Installer Pythons `requests`-pakke. Indlæs følgende miljøværdier via
din normale håndtering af hemmeligheder og konfiguration:

| Variabel | Værdi |
| - | - |
| `LIVING_SECURITY_API_KEY` | Administrations-API-nøgle |
| `LIVING_SECURITY_REGION` | `us` eller `eu` |
| `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | ID for målserviceskontoen |
| `LIVING_SECURITY_OAUTH_CREATE_KEY` | Tidligere gemt genforsøgsnøgle |

```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()
```

Eksemplet foretager én anmodning og beholder resultatet i hukommelsen. Tilføj din hemmelighedsadministrators
skriveoperation på det markerede sted, før du kører det i produktion.
Det kræver bevidst en beslutning efter et usikkert resultat i stedet for stiltiende at
oprette endnu en klient. Netværksfejl kræver også genoprettelsestrinnene nedenfor.

Svar på oprettelse og kvittering bruger `201` og indeholder en `oauth_client`-ressource
med `id`, `service_account_id`, `client_id`, `scopes`, `status`, `created_at` og
`client_secret`. Svar er markeret `Cache-Control: no-store`.

* **`id`** identificerer platformressourcen. Gem den til hentning og tilbagekaldelse.
* **`client_id`** identificerer klienten under tokenudveksling. Det er ikke
  platformressourcens ID. Den kan være `null`, mens oprettelsen afventer.
* **`client_secret`** returneres kun til den anmodning, der gennemfører oprettelsen.
  Hver gentaget oprettelsesanmodning returnerer `null`, også et genforsøg efter et tabt
  succesrespons. Hentning returnerer aldrig en hemmelighed.

## Genopret efter et tabt eller afbrudt svar

Gentag den samme oprettelsesanmodning med den gemte genforsøgsnøgle for at genoprette en
ressourcekvittering. Kvitteringen afspejler den aktuelle tilstand, så en tilbagekaldt klient forbliver tilbagekaldt.
Denne operation bruger ikke den generelle kontrakt om genafspilning af cachede svar i 24 timer
og returnerer ikke en `Idempotent-Replayed`-header.

| Resultat | Næste handling |
| - | - |
| `active`, hemmelighed til stede | Gem hemmeligheden sikkert, og fortsæt onboarding. |
| `active`, hemmelighed mangler | Hemmeligheden kan ikke genskabes. Tilbagekald denne klient, bekræft tilbagekaldelsen, og opret derefter en erstatning med en ny genforsøgsnøgle. |
| `pending` | Oprettelsen er ubekræftet. Behold den samme genforsøgsnøgle. Hent ressourcen for at kontrollere tilstanden; opret ikke dubletter for at omgå usikkerheden. |
| `revoked`, `disabled` eller `expired` | Brug ikke denne klient. Bekræft den tilsigtede kontokonfiguration, før du opretter en erstatning. |
| `409 idempotency_key_reuse` | Anmodningen er ændret under en eksisterende nøgle. Genopret den oprindelige operation, før du beslutter, om en separat oprettelse er nødvendig. |
| `409 invalid_request` | Kontrollér målkontoens status og tildelinger. Hvis klientgrænsen er nået, skal du gennemføre oprydning, før du forsøger igen; en ændring af genforsøgsnøglen frigør ikke kapacitet. |
| `429` | Overhold `Retry-After`; behold den samme nøgle og anmodning. |
| `500`, `503` eller en netværkstimeout | Udfaldet kan være ukendt. Bevar nøglen og inputtene; genopret kvitteringen, før du opretter en ny klient. |
| `401` eller `403` | Løs problemer med adgang til legitimationsoplysninger, tilladelser eller rettigheder, før du forsøger igen. |
| `404` | Bekræft OAuth-aktivering, regional vært og ressourceejerskab. |

Se [fejl](/da/developers/v1/errors/overview) for anmodnings-ID'er og oplysninger om genoprettelse.
Send aldrig en klienthemmelighed eller et adgangstoken sammen med en supportanmodning.

## Undersøg og tilbagekald

Brug din administrationslegitimation og platformressourcens `id`:

| Operation | Anmodning | Succes |
| - | - | - |
| Undersøg aktuel tilstand | `GET /v1/oauth_clients/{id}` | `200`, klientressource uden hemmelighed |
| Tilbagekald adgang | `DELETE /v1/oauth_clients/{id}` | `200`, tilbagekaldt klientressource uden hemmelighed |

Tilbagekaldelse blokerer efterfølgende API-anmodninger for klienten, herunder anmodninger med
allerede udstedte tokens. Den annullerer ikke arbejde, som API'en allerede har accepteret.
Ekstern oprydning af legitimationsoplysninger kan gennemføres senere. Det er sikkert at gentage tilbagekaldelsen,
og den kræver ingen genforsøgsnøgle. Fortsæt med at bruge administrationslegitimationen, hvis den klient,
der tilbagekaldes, selv er en API-kalder.

## Rotér uden at miste adgang

Opret en anden klient med det krævede scope-loft. Gem dens hemmelighed, hent et
token via dit regionale tokenendepunkt, og kontrollér, at integrationen fungerer
med det. Skift integrationen til erstatningen, og tilbagekald derefter den gamle ressource.
Behold en uafhængig administrationslegitimation, så du kan genoprette efter en mislykket udrulning.

Adgangstokens kan ikke give mere end klientens scopes og serviceskontoens
aktuelle tilladelser. Fjernelse af kontotilladelser eller tilbagekaldelse af en klient har
forrang frem for et tokens resterende levetid. Betragt ikke et cachet token som bevis
for, at godkendelsen stadig er gyldig. Hent et nyt adgangstoken, før det udløber, ved at
godkende klienten igen; denne grant bruger ikke refresh tokens.


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