Logowanie przez Microsoft Entra ID w aplikacji firmowej

Logowanie przez Microsoft Entra ID (dawniej Azure Active Directory) pozwala pracownikom wchodzić do aplikacji firmowej tym samym kontem, którego używają w Microsoft 365. Aplikację rejestruje się w tenancie firmy, czyli w jej katalogu użytkowników Microsoft 365. Logowanie odbywa się standardem OpenID Connect. Aplikacja dostaje od Microsoftu podpisany token z informacją, kim jest użytkownik i jakie ma role.

Dzięki temu nie przechowujesz haseł. MFA (logowanie z drugim składnikiem, np. kodem w telefonie), dostęp warunkowy i blokowanie kont działają w aplikacji tak samo jak w poczcie czy Teams. Używamy takiego logowania w naszych narzędziach wewnętrznych.

Co zyskuje Twoja firma przy logowaniu kontem Microsoft 365

• Aplikacja nie przechowuje haseł. Nie musisz ich szyfrować ani resetować. Nie grozi Ci też ich wyciek z Twojej bazy.
• Zasady MFA i dostępu warunkowego skonfigurowane w Entra ID obejmują też Twoją aplikację. Dostęp warunkowy (Conditional Access) wymaga licencji Microsoft Entra ID P1. Ta licencja jest m.in. w Microsoft 365 Business Premium (licencje dostępu warunkowego w Microsoft Learn, stan na 13.11.2026).
• Odejście pracownika obsługujesz w Entra ID. Zablokowanie konta w Entra ID odcina dostęp do wszystkich aplikacji, które z niego korzystają. Nie trzeba pamiętać o osobnym koncie w każdym systemie. Uwaga: aplikacja z długą sesją wpuści użytkownika do jej wygaśnięcia, więc czas sesji ustaw świadomie.
• Lista użytkowników jest jedna. Dział IT zarządza dostępem w znanym sobie panelu i nie musi obsługiwać kolejnej aplikacji.

Jak skonfigurować MFA i dostęp warunkowy w samym Microsoft 365, piszemy na stronie cyberbezpieczeństwa Conetso Group.

Jedna organizacja czy wiele?

Przy rejestracji aplikacji wybierasz, kto może się do niej zalogować. Ta decyzja wpływa na kod, więc trzeba ją podjąć na początku:

Wariant	Kto się loguje	Kiedy wybrać
Jedna organizacja (single tenant)	Użytkownicy i goście z Twojego tenanta	Aplikacja wewnętrzna firmy. Microsoft zaleca ten wariant dla większości aplikacji
Wiele organizacji (multitenant)	Konta służbowe z dowolnego tenanta Entra ID	Aplikacja SaaS dla wielu firm, z których każda ma własny Microsoft 365
Wiele organizacji + konta prywatne	Także konta Microsoft typu Outlook.com	Rzadko w aplikacjach biznesowych

Źródło: rejestracja aplikacji w Microsoft Learn i Tenancy in Microsoft Entra ID, stan na 13.11.2026.

Aplikacja multitenant musi dodatkowo obsłużyć zgodę administratora każdej organizacji i tokeny wystawiane przez różne tenanty. Jeśli budujesz narzędzie dla jednej firmy, nie komplikuj go „na zapas”.

Przepływ logowania: kod autoryzacji z PKCE

Dla aplikacji webowych Microsoft zaleca przepływ kodu autoryzacji (authorization code flow) z PKCE. Przepływ niejawny (implicit grant) to rozwiązanie starsze. Nie włączaj go w nowych aplikacjach, chyba że wymaga tego konkretny scenariusz.

W praktyce nie implementujesz protokołu sam. Korzystasz z bibliotek Microsoftu (MSAL, Microsoft.Identity.Web dla .NET) albo sprawdzonej biblioteki dla Twojego frameworka. Biblioteka weryfikuje podpis tokenu, wystawcę, odbiorcę i datę ważności. Własna weryfikacja tokenu pisana na skróty łatwo pomija któryś z tych warunków. Wtedy aplikacja przyjmie token, którego nie powinna.

Role aplikacji czy grupy?

Samo zalogowanie mówi, kim jest użytkownik. Aplikacja potrzebuje jeszcze informacji, co mu wolno. Entra ID daje dwie drogi:

• Role aplikacji (app roles) definiujesz w rejestracji aplikacji, np. „Pracownik” i „Administrator”. Trafiają do tokenu w polu roles. Należą do aplikacji, więc nie rozjadą się po zmianie nazwy grupy w firmie.
• Grupy przychodzą w polu groups jako identyfikatory grup z tenanta. Gdy użytkownik należy do bardzo wielu grup, Entra ID nie umieszcza ich w tokenie. Trzeba wtedy pobierać je osobno.

W aplikacjach firmowych zalecamy role aplikacji. Administrator przypisuje do nich użytkowników lub całe grupy. Przypisywanie grup do ról wymaga licencji Entra ID P1 (role aplikacji w Microsoft Learn, stan na 13.11.2026). Aplikacja musi przy tym obsłużyć sytuację, w której token nie zawiera żadnej roli. Użytkownik bez roli powinien zobaczyć tylko informację, że nie ma dostępu.

Pamiętaj, że rola w tokenie to dopiero wejście. Sprawdzanie uprawnień do konkretnych danych (np. czy pracownik widzi tylko swoje zlecenia) zostaje po stronie aplikacji.

Dostęp tylko dla wybranych użytkowników

Domyślnie do aplikacji jednej organizacji może się zalogować każdy użytkownik tenanta. Jeśli aplikacja jest tylko dla działu księgowości, włącz w ustawieniach aplikacji korporacyjnej opcję „Assignment required?” („Wymagane przypisanie”). Wtedy token dostaną tylko osoby i grupy przypisane do aplikacji.

Jedna pułapka z dokumentacji Microsoftu: wymóg przypisania nie dotyczy kont z rolą administratora globalnego. Dlatego testuj dostęp na zwykłym koncie, bez ról administracyjnych (ograniczenie aplikacji do wybranych użytkowników w Microsoft Learn, stan na 13.11.2026).

Certyfikat czy sekret klienta?

W środowisku produkcyjnym Microsoft zaleca certyfikaty lub poświadczenia federacyjne. Sekrety traktuje jako rozwiązanie do pracy lokalnej programistów. Własnego poświadczenia potrzebuje każda aplikacja webowa, która loguje użytkowników po stronie serwera albo wywołuje API Microsoftu (interfejsy do wymiany danych z usługami Microsoft). Do wyboru są sekret klienta (ciąg znaków), certyfikat albo poświadczenia federacyjne.

Sekret można ustawić maksymalnie na 24 miesiące, a Microsoft rekomenduje mniej niż 12 (poświadczenia aplikacji w Microsoft Learn, stan na 13.11.2026).

Niezależnie od wyboru pilnuj dwóch rzeczy:

1. Poświadczenie trzymaj poza kodem, w usłudze do przechowywania sekretów, nigdy w repozytorium.
2. Pilnuj terminu wygaśnięcia. Wygasły sekret lub certyfikat wyłącza logowanie z dnia na dzień. Termin odnowienia musi być w czyimś kalendarzu albo w monitoringu.

Lista kontrolna przed uruchomieniem

• Aplikacja zarejestrowana w tenancie firmy z właściwym wariantem (jedna organizacja albo wiele).
• Adresy przekierowania tylko na HTTPS i tylko te, których aplikacja używa.
• Role aplikacji zdefiniowane, w tym rola podstawowa bez podwyższonych uprawnień.
• „Assignment required?” włączone, jeśli aplikacja nie jest dla wszystkich.
• Certyfikat lub poświadczenie federacyjne w produkcji, termin wygaśnięcia w monitoringu.
• Dostęp sprawdzony na zwykłym koncie bez ról administracyjnych.
• Zasady MFA i dostępu warunkowego w tenancie obejmują nową aplikację.

Konto Microsoft 365 może też uruchamiać automatyzacje. Opisaliśmy to we wpisie o webhookach HubSpot i onboardingu w Microsoft 365. Integracje z Microsoft 365 budujemy w ramach usługi integracji systemów.

Jeśli chcesz, żeby pracownicy logowali się do Twojej aplikacji kontem firmowym, napisz do nas. Sprawdzimy konfigurację tenanta i zaplanujemy integrację razem z zespołem bezpieczeństwa Conetso Group.