Skip to main content
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 for at vælge mellem de to metoder og forstå, hvordan servicekonti indgår.
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.
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 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. 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:
Python
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. Se fejl 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: 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.