GitHub zażąda ponownego logowania przed zmianą tokenu lub webhooka

GitHub w komunikacie z 24 września 2026 r. ogłosił publiczny podgląd Proof of Presence dla GitHub Enterprise Cloud. Po włączeniu tej funkcji utworzenie tokenu dostępu, edycja webhooka lub zmiana zabezpieczeń organizacji może wymagać ponownego uwierzytelnienia; po pomyślnym wyzwaniu użytkownik może wykonywać chronione działania w tej samej sesji przeglądarki przez dwie godziny.

Podgląd obejmuje przedsiębiorstwa z Enterprise Managed Users (EMU) na github.com lub w GitHub Enterprise Cloud with data residency (GHEC-DR), korzystające z Microsoft Entra ID jako dostawcy SSO przez SAML albo OIDC. Administrator wybiera ponowne uwierzytelnienie lub wyzwanie MFA. Użytkownik trafia do Entra ID przed chronioną operacją i wraca do GitHuba dopiero po spełnieniu wymaganej polityki.

Jakie zmiany uruchamiają dodatkowe potwierdzenie

Nowa kontrola obejmuje działania, przy których GitHub stosuje tryb sudo, czyli ponowne potwierdzenie tożsamości już zalogowanej osoby. Do chronionych operacji należą między innymi:

• utworzenie tokenu dostępu;
• edycja webhooka;
• zmiana ustawień bezpieczeństwa organizacji;
• wyświetlenie kodów odzyskiwania.

Instrukcja konfiguracji GitHuba wiąże Proof of Presence z tymi samymi działaniami, które wywołują tryb sudo. Lista przykładów nie wyczerpuje więc zakresu ochrony: mogą do niego należeć również operacje przy ustawieniach deweloperskich, uprawnieniach organizacji i regułach repozytoriów. Przy tokenach chodzi między innymi o utworzenie nowego poświadczenia lub unieważnienie wszystkich tokenów, a nie o dodatkowy monit przy zwykłym korzystaniu z już wydanego tokenu.

Scalenie pull requestu jest odrębnym przypadkiem. Możliwość wymagania Proof of Presence przed scaleniem została zapowiedziana na później, więc obecny podgląd nie obejmuje tego działania. Dla administratora granicą są operacje wyzwalające tryb sudo, a nie cała aktywność w repozytorium.

Co dzieje się po przejęciu cookie sesyjnego

Jeśli napastnik skopiuje aktywne cookie przeglądarki, może uzyskać sesję zalogowanego członka przedsiębiorstwa. Po włączeniu Proof of Presence taka sesja sama nie wystarczy do utworzenia nowego tokenu ani edycji webhooka, gdy dla operacji trzeba uzyskać świeże potwierdzenie. GitHub kieruje wtedy przeglądarkę do Entra ID i dopuszcza zmianę dopiero po powrocie z wynikiem zgodnym z polityką firmy.

To mechanizm ograniczający skutki przejęcia sesji w wybranych miejscach. Skradzione cookie nie zostaje przez samo włączenie funkcji unieważnione, podobnie jak wcześniej wydane tokeny. Osoba mająca dostęp do sesji może nadal wykonać działania, które nie wywołują dodatkowej kontroli; skuteczność bariery przed operacją wrażliwą zależy też od tego, czy potrafi przejść wyzwanie Entra ID.

Wybrany wariant ma znaczenie dla tej bariery. Ponowne uwierzytelnienie może, zależnie od firmowej polityki, dopuścić samo hasło. Wariant MFA wymaga również dodatkowego składnika przewidzianego w Entra ID, na przykład aplikacji uwierzytelniającej lub metody biometrycznej. Sama nazwa opcji w GitHubie nie określa więc wszystkich warunków dostępu: o wymaganym sposobie potwierdzenia decyduje także konfiguracja dostawcy tożsamości.

Kto może włączyć podgląd

Warunki dostępu dotyczą jednocześnie modelu kont, środowiska i SSO. Przedsiębiorstwo musi używać EMU w GitHub Enterprise Cloud na github.com albo w GHEC-DR oraz mieć Microsoft Entra ID połączony przez SAML lub OIDC. Samo posiadanie Enterprise Cloud nie wystarcza. Środowisko oparte na kontach osobistych może mieć SAML SSO, lecz ogłoszony zakres tego podglądu wskazuje konta zarządzane EMU.

Ograniczenie do Entra ID jest także praktycznym warunkiem wdrożenia. To firmowy dostawca tożsamości przeprowadza wyzwanie i egzekwuje przypisaną mu politykę, po czym użytkownik wraca do GitHuba. Przedsiębiorstwo korzystające z innego dostawcy nie uzyska tego samego przepływu samym ustawieniem opcji w panelu GitHuba. Status publicznego podglądu oznacza, że dostępność i działanie funkcji mogą jeszcze się zmienić.

Co administrator powinien przygotować w Entra ID

Po włączeniu polityka obejmuje całe przedsiębiorstwo. Administrator przechodzi w ustawieniach przedsiębiorstwa do Settings, potem Authentication security i wybiera w polu Proof of presence wariant Re-authentication albo MFA. To wybór wspólny dla chronionych operacji, więc przed aktywacją trzeba upewnić się, że osoby odpowiedzialne za tokeny, webhooki i ustawienia bezpieczeństwa mogą spełnić wymagania Entra ID.

1. Potwierdź, że przedsiębiorstwo działa na EMU w obsługiwanym wariancie GitHub Enterprise Cloud i korzysta z SSO Microsoft Entra ID przez SAML lub OIDC.
2. Sprawdź, jaką politykę Entra ID zastosuje przy ponownym skierowaniu z GitHuba. Przy Re-authentication hasło może wystarczyć; przy MFA użytkownik musi mieć dostępną dodatkową metodę.
3. Ustal, czy członkowie wykonujący chronione działania mają zarejestrowane wymagane metody i czy mogą przejść wyzwanie. Bez tego nie dokończą wrażliwej zmiany.
4. Po aktywacji przejdź przez chronioną operację, na przykład utworzenie tokenu, i sprawdź przekierowanie do Entra ID, powrót oraz możliwość zakończenia działania.

Jeśli członek przedsiębiorstwa nie przejdzie wyzwania, powinien zwrócić się do administratora przedsiębiorstwa lub osoby zarządzającej firmowym dostawcą tożsamości. Weryfikacja polityki przed aktywacją jest szczególnie ważna przy wyborze MFA: brak dostępnej metody uwierzytelnienia przekłada się wtedy na brak możliwości wykonania chronionej operacji.

Dwugodzinne okno po pomyślnym wyzwaniu

Po udanej weryfikacji użytkownik nie wraca do Entra ID przed każdą kolejną wrażliwą zmianą. Opis WindowsForum wskazuje dwugodzinne okno w tej samej sesji przeglądarki i zwraca uwagę na zasadę trybu sudo, w którym kolejne wrażliwe działanie odnawia licznik. Ponieważ Proof of Presence korzysta z tego modelu sesji, dwie godziny nie muszą być sztywnym końcem liczonym od pierwszego wyzwania.

Ma to znaczenie również przy ocenie przejętej sesji. Dodatkowa kontrola pojawia się, gdy chroniona operacja wymaga nowego potwierdzenia, a aktywne okno pozwala wykonać kolejne takie działania bez następnego wyzwania. Po wygaśnięciu sesji sudo kolejna operacja z tej grupy ponownie kieruje użytkownika do Entra ID. Dla firm czekających na kontrolę przy scalaniu pull requestów następną zmianą będzie dopiero osobne udostępnienie tej zapowiedzianej funkcji.