GitHub Apps: užší oprávnění místo širokého PAT

GitHub v oznámení z 13. října 2026 představil pro GitHub Apps a jemně vymezené osobní přístupové tokeny (PAT) oprávnění repository_creation:write a installation_repositories:write. První umožňuje vytvořit repozitář bez širokého práva k jeho správě, druhé přidat nebo odebrat repozitář z instalace aplikace v organizaci. GitHub zároveň přidal podporu offline_access pro postupný přechod na expirované uživatelské tokeny aplikace.

Integrace, která dosud spoléhá na klasický PAT s rozsahem repo, tak může rozdělit přístup podle skutečných operací. Samotná výměna tokenu však nestačí: tvorba repozitáře, změna přístupu instalace a ostatní volání API potřebují odpovídající oprávnění i správný typ přihlašování. Původní PAT může zmizet až ve chvíli, kdy žádná část integrace jeho široký rozsah nepotřebuje.

Které oprávnění nahradí dosavadní přístup

Mapa migrace začíná u činnosti, kterou integrace provádí, nikoli u názvu starého tokenu. GitHub oddělil vytvoření nového repozitáře od správy existujícího repozitáře a od rozhodnutí, zda k němu smí přistupovat již instalovaná aplikace. Pro každou z těchto operací platí jiná hranice schválení.

Vytvoření repozitáře: pokud tok repozitář pouze zakládá, může místo repository_administration:write žádat o repository_creation:write. Původní administrativní oprávnění zahrnuje také mazání a převod repozitáře. Aplikaci s právem vytvářet repozitáře v organizaci musí nadále schválit vlastník organizace; aplikace nebo uživatel, který repozitář vytvoří, k němu získá přístup.
Přidání či odebrání repozitáře z instalace: příslušná API dříve vyžadovala široký rozsah repo klasického PAT. Nyní podporují GitHub App nebo jemně vymezený PAT s oprávněním installation_repositories:write pro dotčený repozitář. Pokud API volá uživatel, musí být zároveň vlastníkem organizace nebo správcem tohoto repozitáře.
Další práce s repozitářem: čtení obsahu, zápis do něj a administrativní změny se musí posoudit samostatně. Nová oprávnění řeší vytvoření repozitáře a jeho členství v instalaci; nepokrývají automaticky všechna volání, která dosud uspěla díky rozsahu repo.

Správce repozitáře může svůj repozitář přidat k aplikaci, která už je v organizaci nainstalovaná a schválená, bez nového souhlasu vlastníka organizace. Toto zjednodušení se týká úpravy existující instalace: oprávnění na úrovni organizace, správa repozitářů a jejich vytváření zůstávají citlivými sadami vyžadujícími schválení vlastníka. Organizace také může nastavit, aby aplikace k repozitářům přidávali pouze její vlastníci.

Přechod bez výpadku vyžaduje oddělit provozní toky

Nejprve je třeba sepsat volání prováděná starým PAT a přiřadit jim nová oprávnění. U integračního toku, který vytváří repozitář a následně jej zpřístupní jiné instalaci, jde o dvě odlišné operace. Úspěšné vytvoření proto samo o sobě neověřuje, že bude fungovat i změna přístupu instalace nebo další práce s obsahem.

Zavést užší přístup: upravit požadovaná oprávnění GitHub App či jemně vymezeného PAT a zajistit potřebné schválení. Nový tok nejprve směrovat na omezenou část provozu a ověřit zvlášť vytvoření repozitáře i změnu jeho členství v instalaci.
Udržet možnost návratu: během převodu ponechat dosavadní cestu dostupnou pro případ, že některé volání s novým oprávněním selže. Rozšířit provoz až po ověření navazujících operací, které starý PAT také obsluhoval.
Odvolat starý přístup: po převodu všech závislých procesů klasický PAT revokovat. Pouhé odstranění tokenu z konfigurace neukončí jeho platnost; záznam o revokaci má ukázat, kdy široké přihlašovací údaje přestaly fungovat.

Pro změny přístupu k instalaci doporučuje rozbor GitDash zaznamenávat instalaci, repozitář, aktéra, důvod a výsledek akce. V provozním záznamu mají smysl také neúspěšná volání během převodu a informace o tom, který proces ještě používá starou cestu. Hodnoty přístupových a obnovovacích tokenů, soukromé klíče ani celé autorizační hlavičky do logů nepatří.

offline_access mění životní cyklus uživatelského tokenu

Podpora offline_access řeší jinou část migrace než nová práva k repozitářům. Podle dokumentace GitHubu k obnovování tokenů vydá jednotlivá autorizace s tímto rozsahem expirovaný uživatelský přístupový token platný osm hodin a obnovovací token platný šest měsíců, i když aplikace dosud nemá expiraci uživatelských tokenů zapnutou globálně. Použitím obnovovacího tokenu vznikne nová dvojice; použitý obnovovací token i předchozí přístupový token přestanou fungovat.

To umožňuje převádět uživatelské relace postupně. Integrace musí bezpečně uložit obnovovací token, při obnově nahradit starou dvojici novou a zvládnout situaci, kdy obnova selže nebo současně dorazí více požadavků. Parametr scope přitom GitHub App neuděluje další oprávnění: ta se vybírají v registraci aplikace, zatímco offline_access mění tokenový tok dané autorizace.

Zapnutí expirace zpětně nezkrátí platnost dříve vydaných neexpirujících uživatelských tokenů. Ty je nutné odvolat nebo uživatele znovu provést autorizací. Dokud takový token nebo klasický PAT zůstává použitelný, samotné nasazení užších oprávnění starý přístup neodstraní.

Přečtěte si také: