Demistyfikacja OAuth 2.0 w Microsoft Graph: uprawnienia delegowane a uprawnienia aplikacji

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

Automatically translated with AI from the original post. Read the English original

Titelbild: Demystifying OAuth 2.0 in Microsoft Graph: Delegated vs. Application Permissions

Witamy ponownie na blogu! Jeśli zagłębiasz się w automatyzację w Microsoft 365, prawdopodobnie natrafiłeś na ograniczenia narzucane przez natywne łączniki i tradycyjne skrypty. Poruszanie się po meandrach uwierzytelniania może być trudne podczas automatyzacji M365, zwłaszcza gdy trzeba pogodzić solidne zabezpieczenia z płynnym działaniem. Niezależnie od tego, czy budujesz niestandardowe aplikacje dla przedsiębiorstwa, czy konfigurujesz zautomatyzowane procesy działające w tle, dobre zrozumienie modeli uwierzytelniania jest kluczowe. Ten wpis omawia tokeny, zakresy i przepływy zgody, aby pomóc Ci wybrać właściwy model dla zadań wykonywanych w kontekście użytkownika lub bezobsługowych procesów w tle. Przejdźmy od razu do rzeczy i wyjaśnijmy, jak OAuth 2.0 zasila interfejs Microsoft Graph API.

Wprowadzenie do uwierzytelniania w Microsoft Graph

Microsoft Graph to zunifikowana brama do całego ekosystemu Microsoft 365. Zamiast korzystać z oddzielnych, rozproszonych interfejsów API dla Exchange, SharePoint, Teams i Azure Active Directory (obecnie Microsoft Entra ID), deweloperzy i administratorzy IT mogą uzyskiwać dostęp do wszystkich tych usług za pośrednictwem jednego punktu końcowego. Ponieważ Graph kontroluje dostęp do wrażliwych danych firmowych, zabezpieczenie tej bramy wymaga ścisłych ram uwierzytelniania. Zrozumienie, jak tożsamość, tokeny dostępu i uprawnienia się ze sobą łączą, jest pierwszym krokiem do budowy niezawodnych i bezpiecznych automatyzacji, które nie zawiodą pod obciążeniem i nie wywołają alertów bezpieczeństwa.

Zrozumienie OAuth 2.0 w kontekście Microsoft 365

Microsoft Graph w swoim rdzeniu opiera autoryzację na protokole OAuth 2.0. Gdy aplikacja lub skrypt chce komunikować się z Graph, nie może po prostu wysłać poświadczeń w czystej postaci. Zamiast tego musi zażądać tokenu dostępu z platformy tożsamości Microsoft (Entra ID). Token dostępu działa jak bezpieczny cyfrowy paszport. Informuje Microsoft Graph, kto wysyła żądanie, z jakiej aplikacji korzysta i, co najważniejsze, jakie konkretne uprawnienia (zakresy) zostały przyznane temu tokenowi. Bez ważnego tokenu Graph natychmiast odrzuci żądanie standardowym błędem braku autoryzacji.

Uprawnienia delegowane: kiedy działać w imieniu użytkownika

Wybór odpowiedniego modelu uprawnień zależy w całości od charakteru obciążenia. Uprawnienia delegowane są przeznaczone dla aplikacji działających w imieniu zalogowanego użytkownika. Gdy aplikacja używa uprawnień delegowanych, działa w imieniu użytkownika, który jest aktualnie zalogowany. Jeśli użytkownik uruchamia skrypt, aby odczytać własny kalendarz lub zaktualizować zdjęcie profilowe, Graph ocenia żądanie nie tylko pod kątem tego, co aplikacja może robić, ale także tego, do czego dostęp ma dany użytkownik. Jeśli użytkownik nie ma uprawnień do wyświetlania określonej skrzynki pocztowej, token delegowany również takiego dostępu nie przyzna. Ten model sprawdza się idealnie w aplikacjach dla użytkowników, narzędziach interaktywnych i osobistych skryptach produktywności.

Uprawnienia aplikacji: zasilanie bezobsługowych procesów w tle

Z drugiej strony, co zrobić, gdy o północy trzeba uruchomić skrypt lub usługę bez żadnego użytkownika przy klawiaturze? Do bezobsługowych zadań w tle, usług typu daemon i raportowania obejmującego całą dzierżawę potrzebne są uprawnienia aplikacji. W tym modelu aplikacja działa niezależnie od kontekstu użytkownika — działa jako własna tożsamość. Ponieważ nie ma człowieka, który mógłby się zalogować i interaktywnie udzielić zgody, uprawnienia aplikacji wymagają jawnego, wcześniejszego zatwierdzenia przez administratora dzierżawy. Po przyznaniu aplikacja może uzyskiwać dostęp do danych w całej organizacji, co czyni ten model wyjątkowo potężnym w automatyzacji administracyjnej, skryptach wdrożeniowych i monitorowaniu zgodności, ale jednocześnie wymaga ścisłego nadzoru bezpieczeństwa.

Zakresy, tokeny i przepływy zgody

Słownictwo związane z uwierzytelnianiem i autoryzacją bywa przytłaczające, ale rozbicie procesu na etapy pomaga go zrozumieć. Zakresy (scopes) to konkretne uprawnienia, o które żąda Twoja aplikacja, na przykład User.Read.All lub Mail.Read. Gdy użytkownik albo administrator autoryzuje aplikację, przegląda te zakresy i je zatwierdza. Po zatwierdzeniu platforma tożsamości wystawia token JWT (JSON Web Token). Twój kod dołącza ten token do nagłówka HTTP Authorization w każdym żądaniu wysyłanym do Microsoft Graph. Poprawne zarządzanie zgodą pozwala aplikacji sprawnie pobierać te tokeny, bez nieoczekiwanych przeszkód.

Jak uniknąć impasu związanego ze zgodą administratora

Jednym z najczęstszych punktów tarcia, z jakimi borykają się deweloperzy i administratorzy, jest oczekiwanie na zatwierdzenie przez administratora. Gdy aplikacja żąda uprawnień aplikacji o wysokich uprawnieniach lub wrażliwych uprawnień delegowanych, Microsoft Entra ID może wymagać, aby administrator wyraził zgodę na aplikację, zanim zostaną wystawione jakiekolwiek tokeny. Jeśli potok wdrożeniowy zakłada, że użytkownicy sami wyrażą zgodę, a nagle zasady dzierżawy ich blokują, automatyzacja zatrzymuje się całkowicie. Aby uniknąć impasu związanego ze zgodą administratora, zawsze z góry zmapuj wymagane uprawnienia, udokumentuj uzasadnienie biznesowe i uzgodnij z administratorami globalnymi lub administratorami aplikacji wstępną konfigurację zgody na poziomie całej dzierżawy, gdy jest to konieczne.

Typowe pułapki i sposoby ich rozwiązania

Nawet doświadczeni deweloperzy od czasu do czasu natrafiają na irytujące przeszkody autoryzacyjne podczas pracy z Microsoft Graph. Przyjrzyjmy się kilku typowym problemom i sposobom ich rozwiązania:

Działa u mnie, nie działa u innych: Zwykle wynika to z brakującej zgody lub niepoprawnych zakresów. Rozwiązanie: Jasno udokumentuj wymagane zakresy i skonfiguruj zgodę administratora na poziomie całej dzierżawy, tam gdzie to właściwe.
Nadmierne pobieranie dużych ładunków: Pobieranie pełnych list użytkowników bez filtrowania prowadzi do przekroczeń czasu oczekiwania i ograniczania przepustowości. Rozwiązanie: Używaj parametrów $select, $top, stronicowania oraz zapytań delta.
Nieskończone pętle 401/403: Przyczyną jest wygasły token lub użycie uprawnienia delegowanego w zadaniu działającym bez użytkownika. Rozwiązanie: Wdróż solidne odświeżanie tokenów i przełącz się na uprawnienia aplikacji w zadaniach działających w tle.
Przekraczanie limitów żądań: Odpowiedzi 429 oznaczają, że wysyłasz żądania zbyt szybko. Rozwiązanie: Wdróż wykładnicze opóźnienie ponawiania (exponential backoff), respektuj nagłówek Retry-After i grupuj operacje w wsadach (batch).
Rozrost sekretów: Zakodowanie na stałe sekretów klienta w skryptach to poważne ryzyko bezpieczeństwa. Rozwiązanie: Korzystaj z Azure Key Vault, tożsamości zarządzanych lub bezpiecznych zmiennych środowiskowych.

Najlepsze praktyki w zakresie bezpieczeństwa i zarządzania

Gdy otwierasz dostęp do dzierżawy Microsoft 365 przez API, bezpieczeństwo musi być Twoim najwyższym priorytetem. Zgodnie z zasadą najmniejszych uprawnień (least privilege) żądaj wyłącznie absolutnego minimum zakresów potrzebnych aplikacji do działania. Nigdy nie żądaj Directory.AccessAsUser.All tylko po to, aby odczytać nazwę wyświetlaną użytkownika. Prowadź przejrzysty rejestr zgód, opisujący, które aplikacje mają dostęp do Twojej dzierżawy, całkowicie odseparuj rejestracje aplikacji dla środowisk deweloperskiego, testowego i produkcyjnego oraz ustal ścisły harmonogram rotacji sekretów klienta i certyfikatów.

Pierwsze prawdziwe zapytania (przykłady)

Gdy model uwierzytelniania jest już uporządkowany, możesz zacząć wykonywać zapytania do API Graph. Oto kilka praktycznych przykładów, które możesz dostosować:

Nowi pracownicy od określonej daty:
GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
Moje najbliższe spotkania:
GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
Członkowie zespołu w grupie:
GET /groups/{group-id}/members?$select=id,displayName,mail
Zmienieni użytkownicy (delta):
GET /users/delta?$select=id,displayName,mail

Zalecane narzędzia

Wykorzystanie odpowiednich narzędzi znacznie ułatwia budowanie i debugowanie zapytań Microsoft Graph. Graph Explorer to nieocenione, działające w przeglądarce środowisko do testowania punktów końcowych i sprawdzania wskazówek dotyczących zgody. Do pisania kodu pakiety SDK Microsoft Graph (.NET, JavaScript, Python) ukrywają większość niskopoziomowej obsługi HTTP. Rozszerzenia Postman lub REST Client w Twoim IDE świetnie sprawdzają się w zarządzaniu kolekcjami i środowiskami, a Power Automate, Logic Apps i PowerShell doskonale radzą sobie z wizualną i operacyjną automatyzacją procesów.

Często zadawane pytania

Delegowane czy aplikacji – jak wybrać?

Zadania wykonywane w kontekście użytkownika najlepiej odwzorowują uprawnienia delegowane. Zadania bez nadzoru, procesy działające w tle oraz szerokie zadania administracyjne wymagają uprawnień aplikacji wraz z odpowiednią zgodą administratora.

Jak uniknąć ograniczania przepustowości?

Używaj $select, aby ograniczyć rozmiar ładunku, wdrażaj stronicowanie i zapytania delta, tam gdzie to możliwe grupuj żądania, a skrypty zawsze twórz tak, aby prawidłowo obsługiwały kody stanu 429, z logiką ponawiania.

Czy mogę korzystać z Graph bez programowania?

Tak! Możesz prototypować punkty końcowe w Graph Explorer i organizować przepływy pracy w Power Automate. W przypadku złożonej logiki przejdź do oficjalnych zestawów SDK lub skryptów PowerShell.

Czy Graph jest wystarczająco bezpieczny do raportów zgodności?

Zdecydowanie tak. Przy wdrożeniu zgodnym z zasadą najmniejszych uprawnień, scentralizowanym rejestrowaniu zdarzeń, audytowanych przepływach wyrażania zgody i bezpiecznym zarządzaniu sekretami Microsoft Graph spełnia rygorystyczne standardy zgodności przedsiębiorstw.

Podsumowanie

Opanowanie uwierzytelniania w Microsoft Graph to kluczowa umiejętność dla każdego administratora, architekta czy programisty, który chce w pełni wykorzystać możliwości Microsoft 365. Rozumiejąc istotną różnicę między uprawnieniami delegowanymi a uprawnieniami aplikacji, starannie zarządzając zakresami i tokenami oraz stosując rygorystyczne zasady bezpieczeństwa, możesz budować automatyzacje, które są jednocześnie potężne i bezpieczne. Aby zgłębić ten temat, zobaczyć przykłady kodu i poznać zaawansowane strategie obsługi błędów oraz ograniczania przepustowości, koniecznie sprawdź powiązany odcinek podcastu: Automate Microsoft 365 with Microsoft Graph API. Powodzenia w automatyzacji!