--- id: CP-194 slug: oauth-2-delegowanie-dostepu-tokeny lang: pl title: OAuth 2.0 i tokeny dostępu description: Jak OAuth 2.0 daje aplikacji ograniczony dostęp do Pana/Pani konta bez podawania hasła i jak czytać ekran zgody. canonical_url: https://startbrain.io/cyberpedia/pl/articles/oauth-2-delegowanie-dostepu-tokeny/ markdown_url: https://startbrain.io/cyberpedia/pl/articles/oauth-2-delegowanie-dostepu-tokeny.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, „OAuth 2.0 i tokeny dostępu”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/pl/articles/oauth-2-delegowanie-dostepu-tokeny/ (CC BY 4.0) wing: 3 theme: control_access reflex: cr-026 schema: G3 updated: "2026-11-03" translations: pl: https://startbrain.io/cyberpedia/pl/articles/oauth-2-delegowanie-dostepu-tokeny/ fr: https://startbrain.io/cyberpedia/fr/articles/oauth-2-delegation-acces-jetons/ en: https://startbrain.io/cyberpedia/en/articles/oauth-2-delegated-access-tokens/ de: https://startbrain.io/cyberpedia/de/articles/oauth-2-delegierter-zugriff-token/ es: https://startbrain.io/cyberpedia/es/articles/oauth-2-delegacion-acceso-tokens/ it: https://startbrain.io/cyberpedia/it/articles/oauth-2-delega-accesso-token/ nl: https://startbrain.io/cyberpedia/nl/articles/oauth-2-gedelegeerde-toegang-tokens/ pt: https://startbrain.io/cyberpedia/pt/articles/oauth-2-delegacao-acesso-tokens/ sources: - "n": 1 title: Investigate and remediate risky OAuth apps publisher: Microsoft url: https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Access tokens in the Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens accessed: "2026-11-03" - "n": 4 title: Refresh tokens in the Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens accessed: "2026-11-03" - "n": 5 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 6 title: OAuth2 - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html accessed: "2026-11-03" --- # OAuth 2.0 i tokeny dostępu OAuth to otwarty standard uwierzytelniania i autoryzacji oparty na tokenach. Pozwala usłudze zewnętrznej korzystać z informacji z konta bez ujawniania hasła jego właściciela [1]. Weźmy aplikację, która analizuje Pana/Pani kalendarz, aby doradzać w organizacji pracy. Potrzebuje dostępu do kalendarza, ale zamiast otrzymać dane logowania, dostaje token, tworzony po wyrażeniu zgody na specjalnej stronie [1]. Ta strona nazywa się ekranem zgody. ## W 30 sekund - Gdzie to się zdarza: wiele aplikacji zewnętrznych instalowanych przez użytkowników prosi o pozwolenie na dostęp do ich danych i na logowanie się w ich imieniu w innych aplikacjach online [1]. - Czego chce atakujący: skłonić Pana/Panią do udzielenia dostępu złośliwej aplikacji, na przykład po kliknięciu linku otrzymanego w ukierunkowanym phishingu [2]. - Odruch: przed kliknięciem „Akceptuj” sprawdzić, czy żądane uprawnienia odpowiadają przeznaczeniu aplikacji, a jeśli nie, odmówić [1]. - Jeśli to już się stało: administrator może zablokować lub unieważnić aplikację [1]. ## Pytania wprost ### Co się dzieje, gdy akceptuję ekran zgody? Aplikacja otrzymuje token dostępu, który pozwala udostępnić wyłącznie określone informacje z konta [1]. Hasło pozostaje u dostawcy konta. ### Czym jest token dostępu? To poświadczenie przeznaczone do autoryzacji: daje dostęp do określonych zasobów w imieniu użytkownika, który jest już uwierzytelniony. Microsoft porównuje go do kluczy otwierających konkretne drzwi w budynku [3]. Ponieważ otwiera dostęp, jest wrażliwy i stwarza ryzyko, jeśli jest źle chroniony [3]. Jego czas życia jest ograniczony. Na platformie tożsamości Microsoft wartość domyślna jest losowana między 60 a 90 minut, czyli średnio 75 minut [3]. ### Czym jest token odświeżania? Token odświeżania służy do uzyskania nowej pary tokenów, gdy token dostępu wygaśnie. Klient otrzymuje go razem z tokenem dostępu [4]. Żyje dłużej: na platformie Microsoft domyślnie 24 godziny w aplikacjach jednostronicowych i w tych, które używają przepływu uwierzytelniania jednorazowym kodem wysyłanym e-mailem, a 90 dni we wszystkich pozostałych scenariuszach [4]. Aplikacja może dzięki temu dalej pracować w tle, nie pytając o zgodę po każdym wygaśnięciu. ### Dlaczego te tokeny interesują atakujących? Skradziony token pozwala działać z uprawnieniami konta. MITRE ATT&CK opisuje atakujących, którzy używają skradzionych tokenów zamiast danych logowania [5]. Token odświeżania zwiększa ryzyko: jeśli zostanie skradziony, atakujący uzyskuje nowe tokeny dostępu bez angażowania użytkownika [2]. ### Czy można cofnąć aplikacji dostęp? Tak. Po stronie administracji aplikację można zablokować lub unieważnić na stronie aplikacji OAuth, a reguła może zautomatyzować unieważnianie [1]. Po stronie tokenów usługa może unieważnić token odświeżania przed jego wygaśnięciem, na przykład po zmianie hasła lub działaniu użytkownika albo administratora [4]. Skutki zależą od rodzaju tokenu i dokonanej zmiany [4]. ## Jak to działa Występują trzy podmioty. Klient to aplikacja, która prosi o dostęp. Serwer autoryzacji wydaje tokeny po uwierzytelnieniu właściciela danych i uzyskaniu jego zgody. Serwer zasobów przechowuje dane i przyjmuje żądania opatrzone tokenem [6]. Token dostępu zastępuje różne poświadczenia (na przykład nazwę użytkownika i hasło) jednym elementem zrozumiałym dla serwera zasobów. Dzięki temu może mieć krótki czas ważności [6]. Token odświeżania pozwala uzyskać nowy, o tych samych lub węższych uprawnieniach: token dostępu może mieć krótszy czas życia i mniej uprawnień niż te, których udzielił właściciel [6]. Najczęstszy jest token okaziciela: korzystać z niego może każdy, kto go posiada. OWASP zaleca więc ograniczenie go, najlepiej do jednego serwera zasobów, aby zmniejszyć szkody w razie wycieku [6]. Aplikacja z kolei powinna traktować token jak nieprzejrzysty ciąg znaków: jego zawartość ma czytać tylko docelowe API [3]. ## Co Pan/Pani robi Przy ekranie zgody wystarczy kilka sprawdzeń. - Proszę przeczytać żądanie przed zaakceptowaniem. Użytkownicy często klikają „Akceptuj”, nie sprawdzając szczegółów, w tym udzielanych uprawnień [1]. - Proszę porównać uprawnienia z przeznaczeniem aplikacji. Aplikacja powinna prosić tylko o uprawnienia związane z jej celem. Microsoft podaje przykład aplikacji zegara z pełnym dostępem do wszystkich skrzynek pocztowych, co nie odpowiada jej przeznaczeniu [1]. - Proszę uważać na najszersze uprawnienia. MITRE ATT&CK zwraca uwagę, że dostęp offline i dostęp do odczytu e-maili powinny budzić większe podejrzenia, ponieważ atakujący mogą używać API usług online, by szukać w nich danych logowania i poufnej korespondencji [2]. - Proszę zwrócić uwagę na adres przekierowania. Jeśli jest błędnie zapisany lub tworzy skomplikowany ciąg słów wokół oczekiwanej usługi, strona prawdopodobnie próbuje naśladować prawdziwą usługę [2]. - Proszę wybierać popularne aplikacje. Im bardziej aplikacja jest rozpowszechniona, w organizacji i w sieci, tym większa szansa, że jest bezpieczna [1]. - Proszę odmawiać aplikacjom, których Pan/Pani nie rozpoznaje. MITRE ATT&CK zaleca szkolić użytkowników, by nie autoryzowali nieznanych aplikacji zewnętrznych [2]. - Administrator może zbadać podejrzane aplikacje i je usunąć [2]. ## Pułapki ### Fałszywy ekran zgody Atakujący rejestruje aplikację na serwerze autoryzacji, a następnie wysyła ukierunkowany link phishingowy, aby skłonić ofiarę do udzielenia jej dostępu [2]. Przykład podany przez Microsoft: strona zgody może wydawać się wiarygodna przeciętnemu użytkownikowi, choć „Google APIs Explorer” nie ma powodu prosić samego Google o uprawnienia. Aplikacja może więc być próbą phishingu niezwiązaną z Google [1]. Uspokajające nazwy są częste. MITRE ATT&CK odnotowuje, że grupa APT28 używała złośliwych aplikacji podszywających się pod „Google Defender”, „Google Email Protection” i „Google Scanner” wobec użytkowników Gmaila oraz pod „Delivery Service” i „McAfee Email Protection” wobec użytkowników Yahoo [2]. ### Token, który trwa Gdy token zostanie przyznany, aplikacja może uzyskać potencjalnie długotrwały dostęp do funkcji konta [2]. Dzięki tokenowi odświeżania umożliwiającemu dostęp w tle atakujący może na przykład przeszukiwać e-maile i wyliczać kontakty [5]. Zmiana hasła nie zawsze rozwiązuje problem: według tabeli Microsoft niektóre tokeny pozostają aktywne po zmianie hasła przez użytkownika [4]. ### Token skradziony bez pytania o cokolwiek Kradzież tokenu nie zawsze wymaga zgody. MITRE ATT&CK podaje też tokeny skradzione w środowiskach kontenerowych lub w łańcuchach wytwarzania oprogramowania, gdzie służą do uwierzytelniania w innych usługach [2]. Program Kali365 opisano jako taki, który uzyskiwał tokeny dostępu i odświeżania OAuth, nakłaniając ofiary do zatwierdzania żądań autoryzacji urządzenia zainicjowanych przez atakującego [2]. ### Zapomniana aplikacja Aplikacja autoryzowana kiedyś pozostaje połączona, dopóki nikt jej nie usunie. Microsoft zaleca wyszukiwać aplikacje, których data ostatniej autoryzacji nie jest niedawna: mogą być już niepotrzebne [1]. MITRE ATT&CK zaleca administratorom audyt wszystkich aplikacji OAuth i przyznanych uprawnień, a potem audyty okresowe, z badaniem i usuwaniem podejrzanych aplikacji [2]. Dla pracownika oznacza to prosty nawyk: od czasu do czasu przejrzeć listę aplikacji połączonych z kontem i zgłosić te, których nie rozpoznaje. ## Źródła 1. Microsoft, „Investigate and remediate risky OAuth apps”. https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth (dostęp 3 listopada 2026) 2. MITRE ATT&CK, „Steal Application Access Token, Technique T1528 - Enterprise”. https://attack.mitre.org/techniques/T1528/ (dostęp 3 listopada 2026) 3. Microsoft, „Access tokens in the Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (dostęp 3 listopada 2026) 4. Microsoft, „Refresh tokens in the Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens (dostęp 3 listopada 2026) 5. MITRE ATT&CK, „Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise”. https://attack.mitre.org/techniques/T1550/001/ (dostęp 3 listopada 2026) 6. OWASP, „OAuth2 - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html (dostęp 3 listopada 2026) --- Źródło oryginalne: Cyberpedia, publiczna encyklopedia cyberbezpieczeństwa i AI wydawana przez Brain. Wersja kanoniczna: https://startbrain.io/cyberpedia/pl/articles/oauth-2-delegowanie-dostepu-tokeny/ Możesz swobodnie wykorzystywać ten tekst na licencji CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), pod warunkiem podania „Brain, Cyberpedia” wraz z odnośnikiem do powyższego adresu.