Dlaczego samodzielnie tworzone uwierzytelnianie i UX łamią zgodność w aplikacjach M365

By Mirko Peters · 2026-08-11

Witamy ponownie na blogu podcastowym! Jeśli kiedykolwiek spędziłeś tygodnie na zmaganiach z niestandardowymi przepływami OAuth, debugowaniem tajemniczych błędów wygaśnięcia tokenów albo próbami dopasowania M…

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

Titelbild: Why DIY Auth and UX Break Compliance in M365 Apps

Witamy ponownie na blogu podcastu! Jeśli kiedykolwiek spędziłeś tygodnie, walcząc z niestandardowymi przepływami OAuth, szukając przyczyny tajemniczych błędów wygaśnięcia tokenów albo próbując dopasować wygląd aplikacji do stylu Microsoft za pomocą własnego CSS, nie jesteś sam. Tworzenie nowoczesnych aplikacji integrujących się z Microsoft 365 może szybko przerodzić się w ogromną pułapkę inżynieryjną. Wiele zespołów deweloperskich zaczyna z dobrymi intencjami, sądząc, że rozwiązanie własnej produkcji daje pełną kontrolę, a potem zostaje zasypanych lukami audytowymi, brakiem zaufania użytkowników i dużym obciążeniem związanym z bezpieczeństwem. W tym wpisie szczegółowo omówimy, dlaczego budowanie własnych warstw uwierzytelniania i doświadczenia użytkownika od zera jest pułapką zgodności, i pokażemy, jak zmodernizować swój stos technologiczny.

Ten wpis bezpośrednio rozwija nasz najnowszy odcinek podcastu Build Consistent M365 Apps with Microsoft Graph Toolkit. Koniecznie posłuchaj całego odcinka po przeczytaniu tego przewodnika, aby poznać omawiane koncepcje w formie audio!

Przegląd

Większość aplikacji M365 zawodzi w obszarze uwierzytelniania, wyszukiwania w katalogu i UX kalendarza, a do tego wygląda obco w stosunku do marki. Microsoft Graph Toolkit udostępnia utrzymywane, markowane przez Microsoft komponenty React, które integrują się z Graph, obsługują tokeny i zgody oraz zapewniają wiarygodne, zgodne z wymogami doświadczenie od razu po instalacji, a jednocześnie pozwalają bezpiecznie je dostosowywać.

Dla kogo to jest

Deweloperzy frontendowi i liderzy techniczni tworzący aplikacje połączone z M365
Zespoły produktowe potrzebujące szybkiego, zgodnego z wymogami uwierzytelniania i funkcji katalogu
Właściciele bezpieczeństwa i zgodności zmęczeni ryzykownym, samodzielnie tworzonym OAuth i rozjeżdżającym się interfejsem

Dlaczego samodzielne rozwiązania zawodzą (i zagrażają zgodności)

Gdy deweloperzy decydują się samodzielnie tworzyć funkcje uwierzytelniania i wyszukiwania w katalogu, często nie doceniają złożoności ekosystemu tożsamości Microsoft. Rozwiązania własnej produkcji niemal zawsze wiążą się z trzema głównymi kategoriami ryzyka:

Rozjechany OAuth: własne połączenie z MSAL, przechowywanie tokenów, odświeżanie i przypadki brzegowe zgód, które cicho zawodzą lub pozostawiają tokeny bezpieczeństwa wystawione w lokalnej pamięci.
Niezgodność UX: czcionki, kolory, ikony i przepływy, które nie pasują do Microsoftu, prowadząc do utraty zaufania użytkowników i zamieszania podczas monitów o logowanie.
Luki audytowe: niespójne ekrany zgód, nieszczelne wyszukiwanie osób naruszające wewnętrzne zasady zarządzania danymi oraz słabe wyniki dostępności, które nie przechodzą firmowych kontroli zgodności.

Co daje Graph Toolkit

Zamiast budować wszystko od zera, korzystanie ze standardowej biblioteki zmienia wszystko. Microsoft Graph Toolkit działa jako most między kodem frontendowym a interfejsem Microsoft Graph API, zapewniając:

Komponenty React z markowaniem Microsoft, które „po prostu działają” z Graph bez konieczności tworzenia własnych opakowań klienta API.
Wbudowane uwierzytelnianie i zgody (tokeny, odświeżanie, zakresy) z MSAL w tle, zarządzane bezpiecznie zgodnie z najlepszymi praktykami Microsoft.
Obsługa buforowania, ograniczania przepustowości i stanów błędów od razu po instalacji.
Wygląd Fluent UI i dostępność, w tym nawigacja klawiaturą, obsługa czytników ekranu oraz układy dla języków pisanych od prawej do lewej (RTL).
Bezpieczne punkty dostosowywania (właściwości, części i klasy CSS) bez naruszania elementów zgodności, po których użytkownicy rozpoznają autentyczność.

Podstawowe komponenty, których użyjesz od pierwszego dnia

Po przyjęciu zestawu narzędzi natychmiast otrzymujesz dostęp do bogatej biblioteki gotowych widżetów interfejsu. Kilka z nich jest absolutnie niezbędnych w każdej aplikacji dla przedsiębiorstw:

Login: gotowe logowanie i wylogowywanie Microsoft, profil, tokeny i przepływ zgody – bez potrzeby pisania niestandardowego, zagmatwanego kodu OAuth.
PeoplePicker: szybkie wyszukiwanie w katalogu Azure AD z opóźnieniem debounce, z awatarami i możliwością wielokrotnego wyboru; pozwala uniknąć pułapek limitów żądań i stronicowania, na które często natrafiają własne implementacje.
Agenda: wydarzenia z Outlooka prezentowane z charakterystycznymi dla M365 elementami (reguły cykliczności, aktualizacje, strefy czasowe) oraz inteligentne buforowanie zapewniające optymalną wydajność.

Kiedy sięgnąć po Toolkit, a kiedy po własny kod

Ważne jest, by wiedzieć, gdzie przebiegają granice. Należy sięgnąć po zestaw narzędzi, gdy potrzebne jest bezpieczne logowanie, wyszukiwanie w katalogu, kalendarze, zadania, pliki, obecność i profile użytkowników — funkcje, które muszą działać szybko i być spójne z marką. Z drugiej strony warto napisać własny kod, jeśli wymagane są wysoce niestandardowe połączenia danych, niszowe wizualizacje lub systemy spoza Microsoft Graph jako główne źródło danych aplikacji.

Szybki start (ścieżka bez komplikacji)

Utwórz aplikację w Entra ID (środowisko Dev/Test/Prod), włącz MSAL i przyznaj uprawnienia zakresów Graph zgodnie z zasadą najmniejszych uprawnień.
Zainstaluj i podłącz dostawcę w React (dostawca MSAL oraz dostawca Graph Toolkit).
Dodaj komponenty: <Login />, <PeoplePicker />, <Agenda />.
Ustaw zakresy dla każdej strony (np. User.Read, Calendars.Read, People.Read) i sprawdź wymagania dotyczące zgody.
Stylizuj bezpiecznie: zastosuj tokeny motywu i części CSS, zachowując nienaruszone wzorce Microsoft.
Wdróż pilotaż dla niewielkiej grupy użytkowników, zbierz opinie dotyczące UX i wydajności, a następnie rozszerz wdrożenie.

Lista kontrolna przed wdrożeniem produkcyjnym (bezpieczeństwo i niezawodność)

Przed udostępnieniem aplikacji w środowisku produkcyjnym przejdź przez tę szczegółową listę kontrolną, aby upewnić się, że wdrożenie pozostaje bezpieczne i niezawodne przy obciążeniach typowych dla przedsiębiorstw:

Zakresy o najmniejszych uprawnieniach; starannie rozdziel uprawnienia delegowane przez użytkownika od uprawnień aplikacji.
Bezpieczne przechowywanie sekretów i certyfikatów (w miarę możliwości z wykorzystaniem Azure Key Vault).
Czas życia tokenów i logika ponowień: zweryfikuj przepływy odświeżania i zaimplementuj wykładniczy backoff w przypadku błędów 429 lub 503.
Warunkowy dostęp: przetestuj uwierzytelnianie wieloskładnikowe i zasady zgodności urządzeń względem przepływów zestawu narzędzi.
Telemetria: rejestruj identyfikatory żądań, metryki opóźnień, trafienia w pamięci podręcznej i błędy Graph API, aby skutecznie monitorować działanie.
Przegląd dostępności: zweryfikuj nawigację klawiaturą, struktury punktów orientacyjnych oraz współczynniki kontrastu kolorów.
Przegląd marki: upewnij się, że stylizacja Fluent UI i własna powłoka marki pozostają spójne wizualnie.

Uwagi dotyczące wydajności

Wydajność może zadecydować o tym, czy użytkownicy zaakceptują aplikację. Na szczęście komponenty zostały zaprojektowane z myślą o optymalizacji. Korzystają z leniwego ładowania danych i buforowania po stronie klienta, dzięki czemu interfejs pozostaje szybki. Unikaj wzorca N+1 wywołań API, opierając się na wbudowanych komponentach list zestawu narzędzi, i pamiętaj o grupowaniu wyszukiwań użytkowników przy wzbogacaniu wyników wyszukiwania lub stronicowaniu długich list.

Personalizacja bez utraty zaufania

Deweloperzy często obawiają się, że korzystanie z gotowych komponentów ogranicza możliwości brandingu aplikacji. Można jednak łatwo dostosować środowisko, nie rezygnując z bezpieczeństwa. Zamiast modyfikować kod źródłowy, używaj dostępnych właściwości (takich jak zakresy dat i filtry zapytań). Motywuj aplikację za pomocą tokenów Fluent i zmiennych CSS, a podstawowe wzorce Microsoft, takie jak okna logowania i zgody, zawsze utrzymuj rozpoznawalne dla użytkowników.

Typowe pułapki (i rozwiązania)

„Działa lokalnie, nie działa w produkcji” → Zwykle przyczyną są niezgodne identyfikatory URI przekierowania lub zakresy. Dokładnie sprawdź ustawienia rejestracji aplikacji w Entra ID.
Puste wyszukiwanie osób → Brak zakresów People.Read lub User.ReadBasic.All albo zbyt restrykcyjne ustawienia katalogu w dzierżawie.
Pusta agenda → Nie wyrażono zgody na zakres Calendars.Read lub odpytywany jest nieobsługiwany typ skrzynki pocztowej.
Nieskończone monity logowania → Zablokowane pliki cookie innych firm lub restrykcyjne kontrolki sesji dostępu warunkowego. Przetestuj w oknie prywatnym i przejrzyj zasady dostępu warunkowego.

Wskaźniki KPI potwierdzające korzyść

Aby uzasadnić przed kierownictwem inżynierii tę zmianę architektoniczną, śledź wskaźniki takie jak czas do pierwszej funkcjonalności (budowa uwierzytelniania, agendy i selektorów osób przed i po przyjęciu zestawu narzędzi), liczbę błędów uwierzytelniania i zgłoszeń do help desku na tysiąc użytkowników, czas do pełnej interaktywności widoków kalendarza i osób, liczbę problemów z dostępnością wykrytych w każdym wydaniu oraz wyjątki zgodności zgłoszone podczas przeglądów bezpieczeństwa.

Ścieżka migracji (najpierw wymień najbardziej ryzykowne własne elementy)

Zastąp niestandardową obsługę OAuth standardowym komponentem Login.
Zamień autorskie, nieoptymalizowane wyszukiwania w katalogu na komponent PeoplePicker.
Zastąp własne widżety kalendarza komponentem Agenda.
Dodaj funkcje uzupełniające, takie jak Files, Tasks i Presence, w miarę wymagań mapy drogowej produktu.

Podsumowanie

Przestań odtwarzać infrastrukturę Microsoft od podstaw. Microsoft Graph Toolkit daje bezpieczne, spójne z marką bloki budulcowe M365, którym użytkownicy już ufają, a audytorzy zgodności chętnie je akceptują, dzięki czemu zespół inżynierów może skupić się na funkcjach produktu, które faktycznie wyróżniają firmę na rynku.

Gotowy, by zagłębić się w budowanie solidnych i zgodnych z wymogami aplikacji Microsoft 365? Przejdź do podcastu i posłuchaj pełnego odcinka: Build Consistent M365 Apps with Microsoft Graph Toolkit!