> ## 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-clientreferenties > Richt een client met beperkte scope voor een serviceaccount in, ga om met eenmalige secrets en herstel veilig na onzekere requests. Gebruik OAuth-clientreferenties wanneer uw backendintegratie kortlevende toegangstokens nodig heeft of uw beveiligingsbeleid die vereist. Elke client hoort bij één serviceaccount en één organisatie. **OAuth is optioneel:** een API-sleutel met beperkte scope volstaat voor een private serverintegratie die een sleutel veilig kan opslaan en roteren. Raadpleeg [Authenticatie](/nl/developers/v1/authentication) om te kiezen tussen beide methoden en om te begrijpen hoe serviceaccounts hierin passen. OAuth-toegang moet voor uw organisatie zijn ingeschakeld. Bij uw installatie ontvangt u het regionale tokenendpoint, de issuer, de audience en de clientauthenticatiemethode. Als u deze instellingen nodig hebt of geen toegang hebt tot clientbeheer, neemt u contact op met Living Security Support. De client credentials grant vertegenwoordigt uw serviceaccount. Hiermee wordt geen persoon aangemeld en wordt een klant niet gevraagd een applicatie te autoriseren. Gedelegeerde autorisatie via een browser is een afzonderlijke OAuth-mogelijkheid en wordt door deze operaties niet aangeboden. ## Voordat u begint * Maak een [serviceaccount](/nl/developers/developer-hub/service-accounts) aan met uitsluitend de rechten die de integratie nodig heeft. * Gebruik een beheerreferentie met `service_account:manage` en elk recht dat u aan de nieuwe client wilt toekennen. Het doelaccount moet deze rechten eveneens hebben. Een client kan de bevoegdheden van geen van beide accounts uitbreiden. * Kies de [regio](/nl/developers/v1/regions) van de organisatie. API-referenties en OAuth-toegangstokens horen bij de overeenkomstige regionale API-host. * Bewaar het clientsecret en de tokens in uw server-side secretopslag. Plaats ze nooit in browsercode, mobiele applicaties, broncodebeheer of requestlogs. ## Een client aanmaken `POST /v1/oauth_clients` vereist `service_account_id`, een niet-lege lijst met expliciete `scopes` en een `Idempotency-Key`. Wildcards worden niet geaccepteerd. Een client ondersteunt maximaal 100 scopes, met een gecombineerde lengte van maximaal 4.096 tekens. Elk serviceaccount kan maximaal 20 clients of onopgeloste aanmaak-/opschoonoperaties hebben. Intrekking weigert direct de API-toegang. Een client of een onzekere aanmaak bij de provider blijft meetellen voor de limiet totdat de opschoning aan de externe kant is bevestigd. Een verlaten reservering of een aanmaak waarvan is bewezen dat die mislukte voordat het werk bij de provider begon, kan zijn slot veilig vrijgeven. De retrysleutel blijft echter bij de oorspronkelijke poging horen; herstel die receipt voordat u beslist of u een vervanger aanmaakt. Kies één retrysleutel voor deze aanmaakpoging en sla deze op **voordat** u het request verzendt. Gebruik 1–255 zichtbare ASCII-tekens, zonder spaties. Gebruik dezelfde sleutel opnieuw met hetzelfde account, dezelfde scopes, hetzelfde beheerprincipal, dezelfde regio en dezelfde API-versie na een verloren respons. Het roteren van de beheerreferentie onder hetzelfde serviceaccount creëert geen nieuwe retry-identiteit. Installeer het Python-pakket `requests`. Laad de volgende omgevingswaarden via uw gebruikelijke secret- en configuratiebeheer: | Variabele | Waarde | | - | - | | `LIVING_SECURITY_API_KEY` | Beheer-API-sleutel | | `LIVING_SECURITY_REGION` | `us` of `eu` | | `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | ID van het doelserviceaccount | | `LIVING_SECURITY_OAUTH_CREATE_KEY` | Eerder opgeslagen retrysleutel | ```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() ``` Het voorbeeld doet één request en bewaart het resultaat in het geheugen. Voeg de schrijfoperatie van uw secretmanager toe op het gemarkeerde punt voordat u het in productie uitvoert. Het vereist bewust een beslissing na een onzeker resultaat in plaats van stilzwijgend nog een client aan te maken. Netwerkuitzonderingen vereisen ook de onderstaande herstelstappen. Aanmaak- en receiptresponses gebruiken `201` en bevatten een `oauth_client`-resource met `id`, `service_account_id`, `client_id`, `scopes`, `status`, `created_at` en `client_secret`. Responses zijn gemarkeerd met `Cache-Control: no-store`. * **`id`** identificeert de platformresource. Sla deze op voor opvragen en intrekken. * **`client_id`** identificeert de client tijdens de tokenuitwisseling. Dit is niet de ID van de platformresource. Deze kan `null` zijn zolang de aanmaak in behandeling is. * **`client_secret`** wordt alleen geretourneerd aan het request dat de aanmaak voltooit. Elk herhaald aanmaakrequest retourneert `null`, ook een retry na een verloren succesrespons. Bij het opvragen wordt nooit een secret geretourneerd. ## Herstellen na een verloren of onderbroken respons Herhaal hetzelfde aanmaakrequest met de opgeslagen retrysleutel om een resource-receipt te herstellen. De receipt weerspiegelt de actuele status, dus een ingetrokken client blijft ingetrokken. Deze operatie gebruikt niet het algemene replaycontract van 24 uur voor gecachete responses en retourneert geen `Idempotent-Replayed`-header. | Resultaat | Volgende actie | | - | - | | `active`, secret aanwezig | Sla het secret veilig op en ga verder met de onboarding. | | `active`, secret afwezig | Het secret kan niet worden hersteld. Trek deze client in, bevestig de intrekking en maak vervolgens een vervanger aan met een nieuwe retrysleutel. | | `pending` | De aanmaak is niet bevestigd. Behoud dezelfde retrysleutel. Vraag de resource op om de status te controleren; maak geen duplicaten aan om de onzekerheid te omzeilen. | | `revoked`, `disabled` of `expired` | Gebruik deze client niet. Bevestig de beoogde accountconfiguratie voordat u een vervanger inricht. | | `409 idempotency_key_reuse` | Het request is gewijzigd onder een bestaande sleutel. Herstel de oorspronkelijke operatie voordat u beslist of een afzonderlijke aanmaak nodig is. | | `409 invalid_request` | Controleer de status en de toekenningen van het doelaccount. Als de clientlimiet is bereikt, voltooit u eerst de opschoning voordat u het opnieuw probeert; het wijzigen van de retrysleutel maakt geen capaciteit vrij. | | `429` | Houd `Retry-After` aan; behoud dezelfde sleutel en hetzelfde request. | | `500`, `503` of een netwerktime-out | De uitkomst is mogelijk onbekend. Bewaar de sleutel en de invoer; herstel de receipt voordat u een andere client aanmaakt. | | `401` of `403` | Los de toegang met betrekking tot referenties, rechten of entitlements op voordat u het opnieuw probeert. | | `404` | Bevestig de OAuth-inschakeling, de regionale host en het eigendom van de resource. | Zie [fouten](/nl/developers/v1/errors/overview) voor request-ID's en herstelgegevens. Verzend nooit een clientsecret of toegangstoken met een supportaanvraag. ## Opvragen en intrekken Gebruik uw beheerreferentie en de platformresource `id`: | Operatie | Request | Succes | | - | - | - | | Actuele status opvragen | `GET /v1/oauth_clients/{id}` | `200`, clientresource zonder secret | | Toegang intrekken | `DELETE /v1/oauth_clients/{id}` | `200`, ingetrokken clientresource zonder secret | Intrekking blokkeert volgende API-requests van de client, inclusief requests met reeds uitgegeven tokens. Werk dat de API al heeft geaccepteerd, wordt niet geannuleerd. De opschoning van externe referenties kan later worden voltooid. Het herhalen van een intrekking is veilig en vereist geen retrysleutel. Blijf de beheerreferentie gebruiken als de client die wordt ingetrokken zelf een API-aanroeper is. ## Roteren zonder toegang te verliezen Maak een tweede client aan met de vereiste scope-bovengrens. Sla het secret op, verkrijg een token via uw regionale tokenendpoint en controleer of de integratie ermee werkt. Schakel de integratie over naar de vervanger en trek daarna de oude resource in. Houd een onafhankelijke beheerreferentie achter de hand, zodat u kunt herstellen van een mislukte uitrol. Toegangstokens kunnen niet meer toekennen dan de scopes van de client en de actuele rechten van het serviceaccount. Het verwijderen van accountrechten of het intrekken van een client heeft voorrang op de resterende levensduur van een token. Beschouw een gecacht token niet als bewijs dat de autorisatie nog geldig is. Verkrijg vóór het verlopen een nieuw toegangstoken door de client opnieuw te authenticeren; deze grant gebruikt geen refresh-tokens. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.