Fjern GitHub OAuth-adgang – ét valg kan tilbagekalde alle appens tokens

Vil du fjerne en ukendt eller forældet OAuth-app fra din GitHub-konto, skal du åbne Settings → Applications → Authorized OAuth Apps og vælge Revoke ved den relevante post. GitHubs vejledning til autoriserede OAuth-apps beskriver både dette valg og Revoke all, som tilbagekalder alle tokens i oversigten.

Vil du være sikker på, at alle tokens for én bestemt app og bruger bortfalder samlet, kan appens ejer slette brugerens grant via API’et. API-referencen for OAuth-autorisationer angiver, at sletningen også fjerner alle appens tilknyttede OAuth-tokens for den bruger. Har appen haft adgang til en organisations private repositories, skal organisationens adgang kontrolleres særskilt.

Find den personlige autorisation

Begynd på den konto, der autoriserede integrationen. Oversigten under Authorized OAuth Apps viser tokens med adgang til kontoen; undersøg derfor navne, du ikke genkender, og forbindelser, du ikke længere bruger. En app med adgang til private repositories kræver særlig opmærksomhed, fordi adgangen kan omfatte kode, der ikke er offentlig.

1. Klik på dit profilbillede øverst til højre, og vælg Settings.
2. Vælg Applications under Integrations.
3. Åbn fanen Authorized OAuth Apps.
4. Find den relevante post, åbn menuen ved den, og vælg Revoke.

Kontrollér appnavnet, før du vælger handlingen. En tjeneste, du stadig bruger, kan få brug for en ny autorisation, når dens adgang er tilbagekaldt. Hvis du blot har fjernet et lokalt værktøj eller holdt op med at bruge det, bør du stadig kontrollere autorisationen på kontoen: ændringen i din lokale arbejdsgang er ikke det samme som Revoke.

Vælg omfanget: Revoke eller Revoke all

Revoke retter sig mod den valgte post. Revoke all tilbagekalder alle tokens i den personlige OAuth-oversigt og kan dermed også afbryde forbindelser, du fortsat har brug for. Når problemet er én ukendt integration, skal du vælge dens post frem for den samlede handling.

De to valg besvarer forskellige spørgsmål. Revoke er den praktiske handling, når du som kontoejer har fundet den adgang, du vil stoppe. Revoke all passer kun, hvis hensigten faktisk er at tilbagekalde samtlige tokens i oversigten; tjenester, der skal bruges igen, kan derefter kræve ny godkendelse.

Se på oversigten igen efter tilbagekaldelsen. Hvis der stadig står en post fra den app, du ville fjerne, må du tage stilling til den særskilt. Antag ikke, at et klik på én post har samme dokumenterede omfang som app-ejerens sletning af hele brugerens grant.

Hvis du ejer appen: Slet brugerens grant

En OAuth-apps ejer kan bruge API-kaldet til at slette en grant for sin egen app og en bestemt bruger. Det kræver et gyldigt OAuth-access_token som input og Basic Authentication med appens client_id og client_secret. Sletningen rammer den grant, der tilhører tokenets bruger, og alle appens OAuth-tokens knyttet til vedkommende.

API’et har også et særskilt kald til at slette ét app-token. Det er den snævre mulighed, hvis kun det pågældende token skal tilbagekaldes. Sletning af en grant er den bredere handling: bagefter har appen ikke længere adgang til brugerens konto og står ikke længere på brugerens liste over app-autorisationer.

De dokumenterede endpoints kan bruges til både OAuth-app-tokens og brugertokens fra GitHub Apps. Førstnævnte har præfikset gho_, mens sidstnævnte har ghu_. Præfikset hjælper med at skelne tokentyperne; det er valget mellem at slette et token og at slette en grant, der afgør tilbagekaldelsens omfang. Har du ikke appens ejeroplysninger, er den personlige autorisationsoversigt den relevante vej.

Kontrollér organisationens adgang særskilt

En organisationsejer kan fjerne en tidligere godkendt OAuth-apps adgang til organisationens ressourcer. Vejledningen til organisationsadgang placerer handlingen under organisationens Settings → Third-party Access → OAuth app policy, hvor ejeren finder appen og vælger Deny access.

Den kontrol er relevant, hvis integrationen har været brugt med private repositories, som organisationen ejer. Din personlige tilbagekaldelse gælder den adgang, appen fik på dine vegne; organisationsejerens beslutning gælder appens adgang til organisationens ressourcer. Hvis andre medlemmer også har autoriseret appen, er din egen OAuth-oversigt derfor ikke et fuldt billede af dens adgang i organisationen.

Bed organisationsejeren om at undersøge den konkrete app, hvis du ikke selv kan se eller ændre politikken. Oplys appnavnet og hvilke repositories bekymringen gælder, så kontrollen kan rettes mod den rette integration. Deny access er et organisationsvalg og bør ikke forveksles med at rydde din personlige liste over autoriserede apps.

Efterkontrol af resterende integrationer

Åbn Authorized OAuth Apps igen, og kontrollér, at den tilsigtede post ikke længere står der. Gennemgå samtidig de resterende autorisationer for ukendte eller forældede forbindelser. Hvis du valgte Revoke all, må tjenester, du fortsat skal bruge, autoriseres igen efter behov.

Finder du ikke integrationen på OAuth-listen, så undersøg også fanen Authorized GitHub Apps under Applications. Det er en særskilt oversigt over apps, der er autoriseret til at handle på dine vegne. Ved adgang til en organisations repositories bør ejeren desuden kontrollere organisationens app-politik, før gennemgangen betragtes som afsluttet.

Hvis en nødvendig tjeneste beder om ny godkendelse, så kontrollér dens navn og de rettigheder, den anmoder om. Dukker den ukendte forbindelse op igen, er det den tjeneste, der udløser en ny autorisationsanmodning, du skal undersøge.

Læs også:

• API-nøglen lå på GitHub: Sletning af committen stopper ikke misbrug
• Cursor eller GitHub Copilot? Opgavetypen slår den billigste månedspris
• Flyt branch protection til GitHub Rulesets – overlap kan blokere merges