Skip to main content
Bruk OAuth-klientlegitimasjon når backend-integrasjonen din trenger kortlevde tilgangstokener, eller når sikkerhetspolicyen din krever det. Hver klient tilhører én tjenestekonto og én organisasjon. OAuth er valgfritt: en API-nøkkel med begrenset omfang er tilstrekkelig for en privat serverintegrasjon som kan lagre og rotere en nøkkel på en sikker måte. Se Autentisering for å velge mellom de to metodene og for å forstå hvordan tjenestekontoer passer inn.
OAuth-tilgang må være aktivert for organisasjonen din. Oppsettet ditt gir det regionale token-endepunktet, utstederen (issuer), målgruppen (audience) og metoden for klientautentisering. Hvis du trenger disse innstillingene eller ikke har tilgang til klientadministrasjon, kan du kontakte Living Security Support.
Tildelingen av klientlegitimasjon (client credentials grant) representerer tjenestekontoen din. Den logger ikke inn en person og ber ikke en kunde om å autorisere et program. Delegert autorisasjon via nettleser er en separat OAuth-funksjon og tilbys ikke av disse operasjonene.

Før du begynner

  • Opprett en tjenestekonto med kun de tillatelsene integrasjonen trenger.
  • Bruk en administrasjonslegitimasjon med service_account:manage og hver tillatelse du vil gi til den nye klienten. Målkontoen må også ha disse tillatelsene. En klient kan ikke utvide noen av kontoenes myndighet.
  • Velg organisasjonens region. API-legitimasjon og OAuth-tilgangstokener hører hjemme på den tilsvarende regionale API-verten.
  • Oppbevar klienthemmeligheten og tokenene i hemmelighetslagringen på serversiden. Legg dem aldri i nettleserkode, mobilapplikasjoner, kildekontroll eller forespørselslogger.

Opprett en klient

POST /v1/oauth_clients krever service_account_id, en ikke-tom liste med eksplisitte scopes og en Idempotency-Key. Jokertegn godtas ikke. En klient støtter opptil 100 omfang (scopes), med en samlet lengde på høyst 4 096 tegn. Hver tjenestekonto kan ha høyst 20 klienter eller uløste opprettings-/oppryddingsoperasjoner. Tilbakekalling nekter umiddelbart API-tilgang. En klient eller en usikker opprettelse hos leverandøren fortsetter å telle mot grensen helt til ekstern opprydding er bekreftet. En forlatt reservasjon eller en opprettelse som er bevist å ha feilet før arbeid hos leverandøren startet, kan frigi plassen sin på en trygg måte. Gjentakelsesnøkkelen tilhører fortsatt det opprinnelige forsøket; gjenopprett den kvitteringen før du bestemmer deg for å opprette en erstatning. Velg én gjentakelsesnøkkel (retry key) for dette opprettingsforsøket, og lagre den varig før du sender forespørselen. Bruk 1–255 synlige ASCII-tegn, uten mellomrom. Gjenbruk den med samme konto, omfang, administrasjonsprinsipal, region og API-versjon etter et tapt svar. Rotasjon av administrasjonslegitimasjonen under samme tjenestekonto oppretter ikke en ny gjentakelsesidentitet. Installer Python-pakken requests. Last inn følgende miljøverdier gjennom din vanlige hemmelighets- og konfigurasjonshåndtering:
Python
Eksempelet sender én forespørsel og beholder resultatet i minnet. Legg til skriveoperasjonen til hemmelighetsbehandleren din på det markerte punktet før du kjører det i produksjon. Det krever bevisst en beslutning etter et usikkert resultat i stedet for stille å opprette en ny klient. Nettverksunntak krever også gjenopprettingstrinnene nedenfor. Svar på oppretting og kvittering bruker 201 og inneholder en oauth_client-ressurs med id, service_account_id, client_id, scopes, status, created_at og client_secret. Svarene er merket Cache-Control: no-store.
  • id identifiserer plattformressursen. Lagre den for henting og tilbakekalling.
  • client_id identifiserer klienten under tokenutveksling. Det er ikke plattformens ressurs-ID. Den kan være null mens oppretting venter.
  • client_secret returneres kun til forespørselen som fullfører opprettingen. Hver gjentatte opprettingsforespørsel returnerer null, også et nytt forsøk etter et tapt suksessvar. Henting returnerer aldri en hemmelighet.

Gjenopprett etter et tapt eller avbrutt svar

Gjenta den samme opprettingsforespørselen med den lagrede gjentakelsesnøkkelen for å gjenopprette en ressurskvittering. Kvitteringen gjenspeiler gjeldende tilstand, slik at en tilbakekalt klient forblir tilbakekalt. Denne operasjonen bruker ikke den generelle avspillingskontrakten for bufrede svar på 24 timer og returnerer ikke en Idempotent-Replayed-header. Se feil for forespørsels-ID-er og detaljer om gjenoppretting. Send aldri en klienthemmelighet eller et tilgangstoken sammen med en støtteforespørsel.

Inspiser og tilbakekall

Bruk administrasjonslegitimasjonen din og plattformressursen id: Tilbakekalling blokkerer påfølgende API-forespørsler for klienten, inkludert forespørsler med tokener som allerede er utstedt. Den avbryter ikke arbeid som API-et allerede har akseptert. Ekstern opprydding av legitimasjon kan fullføres senere. Det er trygt å gjenta tilbakekallingen, og den krever ingen gjentakelsesnøkkel. Fortsett å bruke administrasjonslegitimasjonen hvis klienten som tilbakekalles selv er en API-kaller.

Roter uten å miste tilgang

Opprett en ny klient med det nødvendige omfangstaket. Lagre hemmeligheten, hent et token via det regionale token-endepunktet ditt, og kontroller at integrasjonen fungerer med det. Bytt integrasjonen over til erstatningen, og tilbakekall deretter den gamle ressursen. Behold en uavhengig administrasjonslegitimasjon slik at du kan gjenopprette etter en mislykket utrulling. Tilgangstokener kan ikke gi mer enn klientens omfang og tjenestekontoens gjeldende tillatelser. Fjerning av kontotillatelser eller tilbakekalling av en klient har forrang over et tokens gjenværende levetid. Ikke anta at et bufret token beviser at autorisasjonen fortsatt er gyldig. Hent et nytt tilgangstoken før utløp ved å autentisere klienten på nytt; denne tildelingen bruker ikke oppdateringstokener (refresh tokens).