Skip to main content
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 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 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. 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:
Python
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. Se fel 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: Å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.