Vælg det rigtige stop
Tilbagekald et sandboxtoken for at stoppe et bestemt testcredential. Nulstil sandbox for at skifte appens testgeneration og lukke tidligere testtokens. Tilbagekald en klienthemmelighed, når den ikke længere skal kunne bruges ved tokenudveksling. Tilbagekald et kundegrant, når appens adgang til én bestemt organisation skal ophøre.
Suspendér appen, når problemet vedrører appen som helhed, eksempelvis kompromitteret infrastruktur eller et ikke længere godkendt formål. Arkivér den, når den er taget ud af brug. Disse handlinger er ikke indbyrdes udskiftelige, og et stop af én kunde må ikke ved en fejl stoppe alle andre kunder, medmindre det er hensigten.
Kundens grant
I visningen Mine kundeautorisationer kan en organisationsejer se grants til sine organisationer og tilbagekalde et grant med begrundelse. Partnerens udvikler får ikke denne oversigt alene gennem sit arbejdsrumsmedlemskab.
Serveren markerer grantet som tilbagekaldt, tilbagekalder dets tokens og annullerer ventende eller leased webhookrækker. Nye gatewaykald afvises. Et gammelt access-token er ikke gyldigt indtil udløb alene, fordi serveren også kontrollerer den registrerede grantstate.
En ny autorisation skaber et nyt grant. Den overtager ikke en gammel idempotenskvittering og genskaber ikke scopes, kunden ikke har accepteret. Integrationens egen forbindelsesstate skal holde det nye grant adskilt fra den gamle adgangsbeslutning.
Appen og revisionen
Suspension eller en ny profilrevision tilbagekalder appens tidligere grants og tokens. Det forhindrer, at gamle kunder fortsat betjenes under en ny redirect- eller adgangsprofil, som deres accept ikke dækkede.
Gamle grants genskabes ikke ved at ændre status tilbage til godkendt. Genoptagelse kræver et nyt kontrolleret forløb. Planlæg derfor suspension som en driftsbeslutning med konsekvensanalyse: hvem rammes, hvilke processer står stille, og hvordan informeres kunder og support?
Grænsen for “øjeblikkeligt stop”
Et tilbagekaldt grant stopper nye autoriserede operationer. Et request, der allerede har passeret kontrollen og er inde i en databasetransaktion, kan være i færd med at afslutte. Låserækkefølgen sikrer en forståelig rækkefølge mellem commit og revokering, men lover ikke en magisk fortrydelse af en allerede udført postering.
En webhook, der allerede er sendt på nettet, kan ikke trækkes tilbage. Modtageren skal behandle tilbagekaldelse i sin egen forbindelsesstate og undlade videre handling, når det er nødvendigt. Data, som partneren allerede lovligt har modtaget, bliver heller ikke slettet ved at invalidere tokenet.
Derfor skal ophørsproceduren indeholde både teknisk stop og håndtering af allerede modtagne data. Sletning, lovpligtig opbevaring, dokumentation og backupforhold må ikke sammenfattes til “alle data er nu væk”, uden at det er bevist.
Mistanke om credentiallæk
Stop den relevante adgang først. Vurder derefter omfanget ud fra sikre referencer: app, credential-id, grant, tidsrum, hændelser og request-id’er. Kopiér ikke den lækkede hemmelighed ind i almindelige supportlogs som bevis.
Rotér hemmeligheder i en kontrolleret rækkefølge. En ny klienthemmelighed ændrer ikke automatisk allerede udstedte access-tokens; tilbagekald grant eller suspendér appen, når hele adgangen skal stoppes. Ved refresh-token-replay tilbagekaldes den pågældende tokenfamilie.
Ophør er også et produktforløb
Vis kunden, hvilken app og organisation der stoppes, og hvad konsekvensen er. Skeln mellem “forbindelse stoppet”, “credential roteret” og “data slettet”. Gem begrundelse og handlingstidspunkt i det relevante kontrolspor.
Stopmekanismerne er koblet til Hours’ kontosletning, retentionjobs og supportgendannelse. Kundens integrationsnavigation viser stoppede forbindelser.