Artykuł jest skierowany do administratora IT po stronie klienta. Opisuje, jakich uprawnień Microsoft Graph wymaga tomHRM, w jakim trybie integracji może działać i co skonfigurować po stronie Microsoft 365.
Tryby integracji z Microsoft 365
tomHRM integruje się z Microsoft 365 przez Microsoft Graph API i obsługuje dwa tryby autoryzacji:
- Delegated permissions – każdy pracownik samodzielnie łączy swój kalendarz przez OAuth. tomHRM działa „w imieniu” użytkownika i widzi tylko jego kalendarz.
- Application permissions – administrator IT konfiguruje raz aplikację Azure AD swojej organizacji w panelu tomHRM. tomHRM zarządza kalendarzami wszystkich pracowników bez indywidualnego logowania, na bazie zgody administratora (admin consent).
Delegated jest szybszy do uruchomienia (nic nie robisz po stronie Azure AD), Application daje pełną kontrolę administratora i nie wymaga akcji od pracowników. Wybór trybu zmieniasz w tomHRM w ustawieniach modułu kalendarza.
Tryb 1: Delegated permissions
W tym trybie pracownik klika „Połącz kalendarz” w tomHRM, jest przekierowany do logowania Microsoft 365 i sam akceptuje listę uprawnień. tomHRM nie wymaga rejestracji własnej aplikacji po Twojej stronie – używa aplikacji Microsoft Entra należącej do tomHRM.
Wymagane uprawnienia Microsoft Graph (delegated)
Pracownik podczas autoryzacji zatwierdza poniższe uprawnienia. Wszystkie są typu „delegated” i co do zasady nie wymagają zgody administratora w domyślnej polityce Microsoft 365.
| Uprawnienie | Po co | Dokumentacja Microsoft |
|---|---|---|
openid |
Identyfikacja użytkownika w protokole OpenID Connect. | link |
offline_access |
Refresh token, żeby tomHRM nie prosił o ponowne logowanie po wygaśnięciu sesji. | link |
User.Read |
Walidacja tokena i pobranie podstawowego profilu zalogowanego użytkownika. | link |
Calendars.ReadWrite |
Tworzenie, aktualizacja i usuwanie wydarzeń w kalendarzu pracownika. | link |
Calendars.ReadWrite.Shared |
Obsługa kalendarzy współdzielonych, z których pracownik korzysta. | link |
Mail.Send |
Opcjonalne, w niektórych konfiguracjach domyślnie nadawane. Nie jest wymagane do samej synchronizacji kalendarzy. | link |
Endpoint OAuth i redirect URI
Jeśli filtrujesz ruch wychodzący lub uzgadniasz reguły w Conditional Access, te adresy będą Ci potrzebne:
| Endpoint autoryzacji | https://login.microsoftonline.com/common/oauth2/v2.0/token |
|---|---|
| Redirect URI | https://<twoja-instancja>.tomhrm.app/calendar/outlook |
| Endpoint Microsoft Graph | https://graph.microsoft.com/v1.0/ |
Wymagania po stronie Microsoft 365
W standardowej polityce Microsoft 365 użytkownik sam akceptuje uprawnienia delegowane i nic dodatkowego nie trzeba robić. Problem pojawia się, jeśli w Twojej organizacji w Azure AD jest włączone ograniczenie zgody użytkownika.
Sprawdź ustawienie: Azure AD → Enterprise applications → Consent and permissions → User consent settings.
Jeśli jest tam Do not allow user consent, pracownik nie zatwierdzi tomHRM samodzielnie i zobaczy ekran wymagający zgody administratora.
W takim wypadku wybierz jedno z trzech rozwiązań:
- Pre-consent dla całej organizacji – administrator akceptuje aplikację tomHRM jednorazowo dla wszystkich użytkowników (Azure AD → Enterprise applications → tomHRM → Grant admin consent). Działa od razu dla całej firmy.
- Zezwolenie na zgodę użytkownika dla zaufanych aplikacji – Azure AD → Enterprise applications → Consent and permissions → Allow user consent for verified publishers, for selected permissions. Zostawia decyzję pracownikowi.
- Workflow „admin consent request” – pracownik wysyła w trakcie autoryzacji prośbę, administrator zatwierdza w panelu Azure.
Najszybsza droga to opcja pierwsza (pre-consent). Po jednym kliknięciu administratora tomHRM jest zatwierdzony dla całej organizacji i pracownicy nie widzą ekranu zgody.
Tryb 2: Application permissions
W tym trybie nie korzystamy z aplikacji tomHRM po stronie Microsoft Entra – Twój administrator IT rejestruje własną aplikację Azure AD i wkleja jej dane w panelu tomHRM. tomHRM uzyskuje token w przepływie client credentials i operuje na kalendarzach pracowników bez ich udziału w OAuth.
Kiedy wybrać Application zamiast Delegated
- chcesz mieć pełną kontrolę nad aplikacją (własny tenant, własne logi, własna polityka rotacji secretu),
- nie chcesz rozsyłać do pracowników instrukcji „kliknij Połącz kalendarz”,
- masz politykę bezpieczeństwa, która nie pozwala na zgodę użytkownika dla aplikacji zewnętrznych.
Wymagane uprawnienia Microsoft Graph (application)
Aplikację rejestrujesz w Microsoft Entra → App registrations i nadajesz jej uprawnienia typu Application. Każde z poniższych wymaga admin consent:
| Uprawnienie | Po co | Dokumentacja Microsoft |
|---|---|---|
Calendars.ReadWrite (Application) |
Tworzenie, aktualizacja i usuwanie wydarzeń w kalendarzach wszystkich pracowników, dla których tomHRM ma synchronizować zdarzenia. | link |
W trybie Application token jest wystawiany dla aplikacji, nie dla użytkownika, więc
openid, offline_access, User.Read nie są potrzebne. tomHRM żąda zakresu https://graph.microsoft.com/.default – Microsoft zwraca wszystkie uprawnienia, które admin nadał aplikacji w Azure AD.Dane wymagane przez tomHRM
Po zarejestrowaniu aplikacji Azure AD wprowadź w panelu tomHRM:
- Client ID – „Application (client) ID” z widoku aplikacji w Azure.
- Tenant ID – „Directory (tenant) ID” Twojej organizacji.
- Client Secret – wartość sekretu utworzonego w sekcji Certificates & secrets.
Client Secret to klucz dostępu do kalendarzy całej organizacji. Po zapisaniu w tomHRM sekret jest szyfrowany w bazie. Mimo to traktuj go jak hasło: trzymaj rotację, nie udostępniaj poza administratorów IT, korzystaj z możliwie krótkich okresów ważności w Azure AD.
Endpointy Microsoft Graph wywoływane przez tomHRM
Lista przydatna, gdy konfigurujesz reguły wyjścia, audytujesz ruch albo wpisujesz tomHRM do polityki Conditional Access.
| Operacja | Tryb Delegated | Tryb Application |
|---|---|---|
| Walidacja tokena / dane usera | GET /v1.0/me |
– |
| Lista kalendarzy | GET /v1.0/me/calendars |
GET /v1.0/users/{email}/calendars |
| Tworzenie wydarzenia | POST /v1.0/me/calendars/{id}/events |
POST /v1.0/users/{email}/calendars/{id}/events |
| Aktualizacja wydarzenia | PATCH /v1.0/me/events/{id} |
PATCH /v1.0/users/{email}/events/{id} |
| Usunięcie wydarzenia | DELETE /v1.0/me/events/{id} |
DELETE /v1.0/users/{email}/events/{id} |
Najczęstsze problemy
AADSTS65001: The user or administrator has not consented to use the application
Pracownik trafił na politykę „Do not allow user consent” w Azure AD. Wybierz jedno z rozwiązań z sekcji Wymagania po stronie Microsoft 365.
AADSTS7000215: Invalid client secret
Sekret w panelu tomHRM jest niepoprawny lub wygasł po stronie Azure AD. Wygeneruj nowy w Certificates & secrets i zaktualizuj w panelu tomHRM (tryb Application) lub zgłoś sprawę przez formularz zgłoszenia (tryb Delegated, jeśli korzystasz z aplikacji tomHRM).
Pracownicy nie widzą synchronizacji po włączeniu trybu Application
Sprawdź, czy uprawnienie Calendars.ReadWrite typu Application ma status „Granted for <Twoja organizacja>” w sekcji API permissions aplikacji w Azure AD. Bez admin consent token jest wystawiony, ale Graph odrzuca operacje na kalendarzach.
Inne pytania
Jeśli powyższe nie odpowiada na Twój przypadek, skorzystaj z Asystenta AI tomHRM albo opisz problem w formularzu zgłoszenia – odpowiemy ze wskazówkami dopasowanymi do Twojej konfiguracji Microsoft 365.