> ## 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-klientuppgifter > Etablera en begränsad klient för tjänstkonton, hantera engångshemligheter och återhämta dig på ett säkert sätt efter osäkra förfrågningar. Använd OAuth-klientuppgifter när er backend-integration behöver kortlivade åtkomsttoken eller när er säkerhetspolicy kräver det. Varje klient tillhör ett tjänstkonto och en organisation. **OAuth är valfritt:** en API-nyckel med begränsat behörighetsomfång räcker för en privat serverintegration som på ett säkert sätt kan lagra och rotera en nyckel. Se [Autentisering](/sv/developers/v1/authentication) för att välja mellan de två metoderna och förstå hur tjänstkonton ingår. OAuth-åtkomst måste vara aktiverad för er organisation. Er konfiguration tillhandahåller den regionala tokenslutpunkten, utfärdaren, målgruppen och autentiseringsmetoden för klienten. Om ni behöver dessa inställningar eller inte kan komma åt klienthanteringen, kontakta Living Securitys support. Beviljandetypen för klientuppgifter representerar ert tjänstkonto. Den loggar inte in en person och ber inte en kund att auktorisera ett program. Delegerad auktorisering via webbläsare är en separat OAuth-funktion och erbjuds inte av dessa operationer. ## Innan du börjar * Skapa ett [tjänstkonto](/sv/developers/developer-hub/service-accounts) med endast de behörigheter som integrationen behöver. * Använd en hanteringsuppgift med `service_account:manage` och varje behörighet som ni vill bevilja den nya klienten. Målkontot måste också ha dessa behörigheter. En klient kan inte utöka något av kontonas behörighet. * Välj organisationens [region](/sv/developers/v1/regions). API-uppgifter och OAuth-åtkomsttoken hör hemma på motsvarande regionala API-värd. * Förvara klienthemligheten och tokenen i er serverbaserade hemlighetslagring. Placera dem aldrig i webbläsarkod, mobilappar, källkodshantering eller förfrågningsloggar. ## Skapa en klient `POST /v1/oauth_clients` kräver `service_account_id`, en icke-tom lista med explicita `scopes` och en `Idempotency-Key`. Jokertecken accepteras inte. En klient stöder upp till 100 scopes med en sammanlagd längd på högst 4 096 tecken. Varje tjänstkonto kan ha högst 20 klienter eller olösta skapande-/rensningsoperationer. Återkallelse nekar API-åtkomst omedelbart. En klient eller ett osäkert skapande hos leverantören räknas fortsatt mot gränsen tills fjärrrensningen har bekräftats. En övergiven reservation eller ett skapande som bevisligen misslyckades innan arbetet hos leverantören påbörjades kan på ett säkert sätt frigöra sin plats. Dess återförsöksnyckel tillhör fortfarande det ursprungliga försöket; återhämta det kvittot innan ni avgör om en ersättare ska skapas. Välj en återförsöksnyckel för detta skapandeförsök och spara den **innan** förfrågan skickas. Använd 1–255 synliga ASCII-tecken, utan blanksteg. Återanvänd den med samma konto, scopes, hanteringsprincipal, region och API-version efter ett förlorat svar. Att rotera hanteringsuppgiften under samma tjänstkonto skapar ingen ny återförsöksidentitet. Installera Pythons `requests`-paket. Läs in följande miljövärden via er vanliga hantering av hemligheter och konfiguration: | Variabel | Värde | | - | - | | `LIVING_SECURITY_API_KEY` | API-nyckel för hantering | | `LIVING_SECURITY_REGION` | `us` eller `eu` | | `LIVING_SECURITY_SERVICE_ACCOUNT_ID` | ID för målets tjänstkonto | | `LIVING_SECURITY_OAUTH_CREATE_KEY` | Tidigare sparad återförsöksnyckel | ```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() ``` Exemplet gör en förfrågan och behåller resultatet i minnet. Lägg till skrivoperationen i er hemlighetshanterare vid den markerade punkten innan ni kör det i produktion. Det kräver avsiktligt ett beslut efter ett osäkert resultat i stället för att i tysthet skapa ytterligare en klient. Nätverksundantag kräver också återhämtningsstegen nedan. Svar för skapande och kvitton använder `201` och innehåller en `oauth_client`-resurs med `id`, `service_account_id`, `client_id`, `scopes`, `status`, `created_at` och `client_secret`. Svaren är markerade `Cache-Control: no-store`. * **`id`** identifierar plattformsresursen. Spara det för hämtning och återkallelse. * **`client_id`** identifierar klienten vid tokenutbyte. Det är inte plattformsresursens ID. Det kan vara `null` medan skapandet väntar. * **`client_secret`** returneras endast till den förfrågan som slutför skapandet. Varje upprepad skapandeförfrågan returnerar `null`, även ett omförsök efter ett förlorat lyckat svar. Hämtning returnerar aldrig någon hemlighet. ## Återhämta efter ett förlorat eller avbrutet svar Upprepa samma skapandeförfrågan med den sparade återförsöksnyckeln för att återhämta ett resurskvitto. Kvittot återspeglar aktuellt tillstånd, så en återkallad klient förblir återkallad. Den här operationen använder inte det allmänna avtalet om återuppspelning av cachade svar i 24 timmar och returnerar inte något `Idempotent-Replayed`-huvud. | Resultat | Nästa åtgärd | | - | - | | `active`, hemlighet finns | Spara hemligheten säkert och fortsätt introduktionen. | | `active`, hemlighet saknas | Hemligheten kan inte återskapas. Återkalla den här klienten, bekräfta återkallelsen och skapa sedan en ersättare med en ny återförsöksnyckel. | | `pending` | Skapandet är obekräftat. Behåll samma återförsöksnyckel. Hämta resursen för att granska tillståndet; skapa inte dubbletter för att kringgå osäkerheten. | | `revoked`, `disabled` eller `expired` | Använd inte den här klienten. Bekräfta den avsedda kontokonfigurationen innan ni etablerar en ersättare. | | `409 idempotency_key_reuse` | Förfrågan ändrades under en befintlig nyckel. Återhämta den ursprungliga operationen innan ni avgör om ett separat skapande behövs. | | `409 invalid_request` | Kontrollera målkontots status och beviljade behörigheter. Om dess klientgräns nåddes, slutför rensningen innan ni försöker igen; att byta återförsöksnyckel frigör ingen kapacitet. | | `429` | Följ `Retry-After`; behåll samma nyckel och förfrågan. | | `500`, `503` eller en nätverkstimeout | Utfallet kan vara okänt. Bevara nyckeln och indata; återhämta kvittot innan ni skapar ytterligare en klient. | | `401` eller `403` | Åtgärda åtkomsten vad gäller uppgifter, behörighet eller entitlement innan ni försöker igen. | | `404` | Bekräfta OAuth-aktivering, regional värd och resursägarskap. | Se [fel](/sv/developers/v1/errors/overview) för förfrågnings-ID:n och information om återhämtning. Skicka aldrig en klienthemlighet eller en åtkomsttoken med en supportförfrågan. ## Granska och återkalla Använd er hanteringsuppgift och plattformsresursens `id`: | Operation | Förfrågan | Lyckat resultat | | - | - | - | | Granska aktuellt tillstånd | `GET /v1/oauth_clients/{id}` | `200`, klientresurs utan hemlighet | | Återkalla åtkomst | `DELETE /v1/oauth_clients/{id}` | `200`, återkallad klientresurs utan hemlighet | Återkallelse blockerar efterföljande API-förfrågningar för klienten, inklusive förfrågningar med redan utfärdade token. Den avbryter inte arbete som API:t redan har godtagit. Fjärrrensningen av uppgifter kan slutföras senare. Det är säkert att upprepa återkallelsen och ingen återförsöksnyckel behövs. Fortsätt använda hanteringsuppgiften om klienten som återkallas själv är en API-anropare. ## Rotera utan att förlora åtkomst Skapa en andra klient med det scope-tak som krävs. Spara dess hemlighet, hämta en token via er regionala tokenslutpunkt och verifiera att integrationen fungerar med den. Växla integrationen till ersättaren och återkalla sedan den gamla resursen. Behåll en oberoende hanteringsuppgift så att ni kan återhämta er från en felaktig utrullning. Åtkomsttoken kan inte ge mer än klientens scopes och tjänstkontots aktuella behörigheter. Att ta bort kontobehörigheter eller återkalla en klient har företräde framför en tokens återstående livslängd. Betrakta inte en cachad token som bevis på att auktoriseringen fortfarande är giltig. Hämta en ny åtkomsttoken före utgången genom att autentisera klienten igen; den här beviljandetypen använder inte uppdateringstoken. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.