LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Perspektywy
Kalendarz Google
Dołącz do społeczności Slack
Spis treści
01Dlaczego Microsoft Graph OAuth będzie obowiązkowe w 2026 roku
023 przepływy OAuth obsługiwane przez firmę Microsoft
03Rejestracja aplikacji w Microsoft Entra (7 kroków)
04Wybieranie właściwego punktu końcowego autoryzacji
Microsoft Graph OAuth 2026
Microsoft Graph OAuth: Uwierzytelnianie skrzynki pocztowej Outlook i Microsoft 365
Kompletny przewodnik po Microsoft Graph OAuth dla deweloperów SaaS na rok 2026. Obejmuje rejestrację aplikacji Microsoft Entra, punkty końcowe autorytetu, zakresy poczty, uprawnienia delegowane i aplikacyjne, zgodę administratora, kod autoryzacyjny + PKCE, rotację tokenów odświeżania, kody błędów AADSTS oraz jak Unipile eliminuje 5 tygodni kodowania OAuth w 5 minut.
import żądania
# Krok 1: Wygeneruj link do uwierzytelniania w usłudze hostingowej
response = requests.stanowisko(
"https://apiXXX.unipile.com:XXX
/api/v1/hosted/accounts/link",
nagłówki={"X-API-KEY": klucz_api},
json={
"typ": "create",
"dostawcy": ["MICROSOFT"],
"api_url": twój_dsn,
"ważne do": "2026-12-31T23:59:59Z"
}
)
# Krok 2: Przekieruj użytkownika na adres URL
auth_url = response.json()["url"]
# Unipile obsługuje cały proces OAuth
# wraz z Entrą, lunetami, żetonami i odświeżeniemObsługa Microsoft OAuth zakończona. Skrzynka pocztowa gotowa.
Kontekst 2026
Dlaczego Microsoft Graph OAuth jest nie do negocjacji w 2026 roku
Jeśli Twoja aplikacja SaaS odczytuje, wysyła lub synchronizuje pocztę e-mail Outlook lub Microsoft 365, uwierzytelnianie Microsoft Graph OAuth nie jest już opcjonalne. Trzy poważne wycofania sprawiły, że uwierzytelnianie podstawowe (Basic Auth), starsze protokoły i hasła aplikacji stały się przestarzałe. OAuth 2.0 za pośrednictwem interfejsu API Microsoft Graph jest jedyną obsługiwaną ścieżką.
Basic Auth - W pełni przestarzałe
Microsoft wyłączył podstawowe uwierzytelnianie dla Exchange Online w październiku 2022 r. Dotyczy to protokołów IMAP, POP3, SMTP, EWS, MAPI, OAB, Outlook Anywhere i RPC over HTTP. Nie ma wyjątków ani pozostałych okresów karencji.
Wyłączone paź. 2022
EWS - Harmonogram zachodu słońca
Exchange Web Services (EWS) jest w trybie konserwacji. Firma Microsoft ogłosiła brak nowych funkcji i zaleca migrację do Microsoft Graph. Chociaż nie zostało jeszcze całkowicie wyłączone, tworzenie nowych integracji w EWS w 2026 roku będzie decyzją obciążoną długiem technologicznym, której będziesz żałować.
Tryb konserwacji
OAuth 2.0 - Wymagany Standard
Microsoft Graph OAuth przez Microsoft Entra ID (wcześniej Azure AD) to jedyna oficjalnie wspierana metoda uwierzytelniania dla produkcyjnych aplikacji SaaS uzyskujących dostęp do skrzynek pocztowych Outlook i Microsoft 365 w 2026 roku. Ten przewodnik obejmuje pełną implementację.
Wymagany standard
Co odblokowuje Microsoft Graph OAuth
Czytaj, wysyłaj i synchronizuj skrzynki pocztowe Outlook w imieniu uwierzytelnionych użytkowników
Dostęp do skrzynek pocztowych Microsoft 365 i osobistych Outlook.com za pomocą jednej rejestracji aplikacji
Długożyjące tokeny odświeżania z automatycznym obrotem (brak ponownego uwierzytelniania dla aktywnych użytkowników)
Kontrola zakresu na poziomie szczegółowym: żądaj tylko uprawnień, których Twoja aplikacja faktycznie potrzebuje
Obsługa wielu najemców: jedna rejestracja aplikacji służy wszystkim najemcom klientów
Zgodność z firmowymi zasadami dostępu warunkowego i uwierzytelniania wieloskładnikowego
Przepływy OAuth
3 przepływy OAuth, które obsługuje firma Microsoft (i których potrzebuje SaaS)
Platforma tożsamości firmy Microsoft obsługuje kilka typów przyznawania OAuth 2.0. Wybranie niewłaściwego jest częstym źródłem marnowania czasu inżynierów. Oto podsumowanie dla aplikacji SaaS, które uzyskują dostęp do poczty e-mail w imieniu użytkowników.
Zalecane dla SaaS
Kod autoryzacyjny + PKCE
RFC 6749 Sekcja 4.1 + RFC 7636
Użytkownik zostaje przekierowany na stronę logowania Microsoft, uwierzytelnia się i udziela zgody. Twoja aplikacja wymienia zwrócony kod autoryzacyjny na tokeny dostępu i odświeżania. PKCE (Proof Key for Code Exchange) zapobiega atakom polegającym na przechwyceniu kodu i jest obowiązkowe dla klientów publicznych oraz zalecane dla wszystkich klientów w 2026 roku.
Użyj tego dla aplikacji SaaS uzyskujących dostęp do skrzynek pocztowych użytkowników
Dane uwierzytelniające klienta
OAuth 2.0 Sekcja 4.4 (tylko aplikacja)
Brak interakcji z użytkownikiem. Twoja aplikacja uwierzytelnia się jako ona sama, używając identyfikatora klienta i tajnego klucza (lub certyfikatu). Wymaga uprawnień aplikacji (nie delegowanych), co oznacza, że administrator dzierżawy musi udzielić zgody na dostęp do wszystkich skrzynek pocztowych w organizacji. Brak ekranu zgody użytkownika.
Tylko do narzędzi wewnętrznych z dostępem przyznanym przez administratora
Przepływ kodu urządzenia
OAuth 2.0 Grant autoryzacji urządzenia
Zaprojektowane dla urządzeń bez przeglądarki (CLI, IoT, inteligentne telewizory). Użytkownik odwiedza adres URL na innym urządzeniu w celu uwierzytelnienia. Nie dotyczy aplikacji internetowych SaaS, w których możliwy jest przekierowanie.
Nie dotyczy standardowych aplikacji internetowych SaaS
Konfiguracja krok po kroku
Rejestracja aplikacji Microsoft Entra: 7 kroków
Zanim Twoja aplikacja będzie mogła zażądać tokenów OAuth, musisz mieć zarejestrowaną aplikację w usłudze Microsoft Entra ID (wcześniej Azure Active Directory). Oto dokładne kroki, w tym, które wartości pól mają znaczenie, a które są kosmetyczne.
1
Utwórz rejestrację aplikacji w witrynie Azure Portal
Przejdź do
portal.azure.com, idź do Microsoft Entra ID (wyszukaj na górnym pasku), następnie Rejestracje aplikacji, a następnie kliknij + Nowa rejestracja. Zobacz pełna dokumentacja Microsoft OAuth aby uzyskać dodatkowe informacje.Nazwa
Nazwa Twojej aplikacji. Jest ona widoczna dla użytkowników na ekranie zgody firmy Microsoft. Użyj nazwy produktu, a nie identyfikatora technicznego.
Obsługiwane typy kont
W przypadku wielodostępnej platformy SaaS przeznaczonej zarówno dla użytkowników biznesowych, jak i prywatnych: wybierz
Konta w dowolnym katalogu organizacyjnym (dowolny tenant Microsoft Entra ID – wielodostępny) oraz osobiste konta Microsoft. odpowiada to /wspólny punkt końcowy autoryzacji.Wskazówka: Jeśli obsługujesz tylko firmowe konta Microsoft 365 (nie osobiste Outlook.com), zaznacz tylko opcję "Wielodostępny". W tym przypadku używany jest
/organizacje zarządza i zmniejsza powierzchnię zgody. Więcej na temat punktów końcowych autorytetu w sekcji 4.2
Konfiguruj identyfikatory URI przekierowania
Po rejestracji przejdź do Uwierzytelnianie na lewym panelu. Dodaj platformę: wybierz sieć. Dodaj swój adres URI przekierowania(a), czyli adres URL, na który Microsoft przekieruje użytkownika z powrotem z kodem autoryzacji.
Typ platformy
sieć dla aplikacji po stronie serwera. Użyj Aplikacja jednostronicowa dla przepływów po stronie klienta (automatycznie włącza PKCE).URI przekierowania
W produkcji musi być HTTPS. Przykład:
https://app.yourproduct.com/auth/microsoft/callback. Wymagane dokładne dopasowanie, jakiekolwiek odchylenie powoduje AADSTS50011.Adres URL wylogowania (opcjonalnie)
Microsoft wywoła ten adres URL, gdy użytkownik wyloguje się z dowolnej aplikacji w swojej dzierżawie. Opcjonalne dla integracji obejmujących tylko pocztę e-mail.
Częsty błąd: localhost adresy URIs są dozwolone podczas rozwoju (
http://localhost:3000/callbackale produkcyjne identyfikatory URI muszą używać HTTPS. Zarejestruj oba oddzielnie.3
Dodaj uprawnienia Microsoft Graph API
Idź do Uprawnienia API. Kliknij + Dodaj uprawnienie, wybierz Microsoft Graph, potem Uprawnienia delegowane. Dodaj zakresów, których wymaga Twoja aplikacja.
Minimum do odczytu
Mail.Read, dostęp offline, openid, profilDo odczytu + wysyłki
Mail.ReadWrite, Mail.Send, dostęp offline, openid, profildostęp offline
Krytyczne. Bez tego zakresu firma Microsoft nie wydaje tokenu odświeżającego. Twoi użytkownicy będą musieli uwierzytelniać się ponownie co 60-90 minut.
Uwaga: Dodawanie uprawnień tutaj nie przyznaje ich, a jedynie deklaruje intencję. Użytkownik wyraża zgodę po zakończeniu przepływu OAuth. Zgoda administratora jest wymagana dla niektórych zakresów o podwyższonych uprawnieniach (patrz sekcja 7).
4
Wygeneruj Klucz Klienta
Idź do Certyfikaty i sekrety. Kliknij + Nowy sekret klienta. Ustaw opis i datę wygaśnięcia.
Rekomendacja dotycząca terminu ważności
730 dni (24 miesiące) to maksimum. Ustaw przypomnienie kalendarza 60 dni przed wygaśnięciem, rotacja wygasłego sekretu powoduje natychmiastowe błędy uwierzytelniania u wszystkich użytkowników.
Skopiuj wartość natychmiast
Sekretna wartość jest wyświetlana tylko raz. Przechowaj je w swoim menedżerze sekretów (np. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault). Nigdy więcej nie zostanie wyświetlona po opuszczeniu tej strony.
Zalecana alternatywa: Do produkcji użyj certyfikatu zamiast sekretu klienta. Certyfikaty są bezpieczniejsze (klucz asymetryczny), nigdy nie wygasają przypadkowo i są preferowane przez firmę Microsoft dla aplikacji klasy enterprise.
5
Skopiuj swój identyfikator klienta i identyfikator dzierżawy
Z Przegląd strony rejestracji aplikacji, skopiuj dwie wartości, których będziesz potrzebować w każdym żądaniu OAuth:
ID aplikacji (klienta)
Identyfikator UUID, który jednoznacznie identyfikuje rejestrację Twojej aplikacji. Używany jako
client_id parametrze we wszystkich żądaniach uwierzytelniania.Identyfikator katalogu (dzierżawy)
Identyfikator najemcy Twojej organizacji. Używany w adresach URL poleceń jednonajemcy. W przypadku aplikacji wielonajemcowych używasz
/wspólny zamiast, ale zachowaj tę wartość dla adresów URL zgody administratora.6
Włącz tokeny identyfikacyjne (opcjonalne, ale zalecane)
Z powrotem Uwierzytelnianie, pod Domyślne udzielenie uprawnień i przepływy hybrydowe, możesz włączyć Tokeny identyfikacyjne. Pozwala to na otrzymanie JWT z danymi tożsamości użytkownika (imię, email, identyfikator dzierżawy) wraz z tokenem dostępu, co jest przydatne podczas procesów onboardingu, gdy chcesz wstępnie wypełnić dane profilu użytkownika.
Prognoza na 2026 rok: Dla czystych przepływów auth-code + PKCE, tokeny ID są zwracane przez punkt końcowy tokenu, a nie przez grant niejawny. Nie musisz włączać grantu niejawnego. Włącz go tylko wtedy, gdy masz starszą aplikację SPA, która nie może używać PKCE.
7
Opcjonalnie: Zweryfikuj swoją domenę wydawcy
W Branding i nieruchomości, ustaw domenę wydawcy na domenę swojego produktu. Zastępuje to etykietę "niezweryfikowane" na ekranie zgody nazwą Twojej domeny. W przypadku aplikacji wielodostępnych skierowanych do klientów korporacyjnych, ukończenie weryfikacji Microsoft Partner Network i uzyskanie statusu "zweryfikowanego wydawcy" usuwa wyraźne ostrzeżenie "Ta aplikacja nie jest często używana".
Domena wydawcy
Domena, którą posiadasz i zweryfikowałeś za pomocą rekordu TXT lub przepływu walidacji domeny w usłudze App Service.
Zweryfikowany wydawca
Wymaga identyfikatora Microsoft Partner Network (MPN) powiązanego z zaufaną tożsamością firmy. Trwa to 1-5 dni roboczych. Znacząco zwiększa konwersję klientów korporacyjnych na ekranach zgód.
Punkty końcowe autoryzacji
Wybór odpowiedniego punktu końcowego autoryzacji firmy Microsoft
Adres URL urzędu (authority URL), którego używasz w żądaniach OAuth, określa, które typy kont Microsoft mogą się uwierzytelnić i jakie tokeny otrzymasz. Błędne skonfigurowanie tego powoduje ciche błędy, przez które niektórzy użytkownicy nie mogą się w ogóle uwierzytelnić.
| URL autorytetu | Akceptuje | Przypadek użycia | Zastrzeżenia |
|---|---|---|---|
| /wspólnyNajlepsze SaaS | Zarówno konta Microsoft Entra (służbowe/szkolne), jak i osobiste konta Microsoft (Outlook.com, Hotmail, Live) | Wielodostępna usługa SaaS obsługująca wszystkich użytkowników Microsoft. Jedno zakończenie obsługuje całą bazę użytkowników. | Token uwierzytelniający jest wystawiany przez główny tenant każdego użytkownika, a nie przez twojego. Weryfikacja tokenu musi używać wystawcy specyficznego dla tenantu lub akceptować wielu wystawców. Nie można wymusić zasad dostępu warunkowego. |
| /organizacje | Konta Microsoft Entra ID (służbowe/szkolne). Żadne osobiste konta Microsoft. | Rozwiązanie B2B SaaS skierowane wyłącznie do klientów korporacyjnych, nigdy do użytkowników indywidualnych Outlook.com. | Użytkownicy z osobistymi kontami Microsoft otrzymają błąd. Dopuszczalna prostsza walidacja tokenu (wzorzec pojedynczego wystawcy). |
| konsumenci | Tylko osobiste konta Microsoft (Outlook.com, Hotmail, Live). | Aplikacje konsumenckie skierowane do skrzynek odbiorczych. Rzadkość w przypadku SaaS B2B. | Konta Microsoft 365 dla firm są odrzucane. Nieprzydatne dla modelu SaaS obsługującego użytkowników biznesowych. |
| /{identyfikator-dzierżawcy} | Konta w określonym dzierżawcy Microsoft Entra. | Narzędzia wewnętrzne dla jednego dzierżawcy (aplikacja własnej firmy). Przepływy zgody administratora skierowane do określonego dzierżawcy. Używane również we wzorcach adresów URL przekierowań zgody administratora. | Każdy inny użytkownik dzierżawcy jest odrzucany. Odpowiednie tylko dla aplikacji wewnętrznych lub gdy celowo ograniczamy dostęp do dzierżawcy jednego klienta. |
/wspólny
Najlepsze SaaS
Akceptuje
Zarówno konta Microsoft Entra (służbowe/szkolne), jak i osobiste konta Microsoft (Outlook.com, Hotmail, Live)
Przypadek użycia
Wielodostępna usługa SaaS obsługująca wszystkich użytkowników Microsoft. Jedno zakończenie obsługuje całą bazę użytkowników.
Zastrzeżenia
Token uwierzytelniający jest wystawiany przez główny tenant każdego użytkownika, a nie przez twojego. Weryfikacja tokenu musi używać wystawcy specyficznego dla tenantu lub akceptować wielu wystawców. Nie można wymusić zasad dostępu warunkowego.
/organizacje
Akceptuje
Konta Microsoft Entra ID (służbowe/szkolne). Żadne osobiste konta Microsoft.
Przypadek użycia
Rozwiązanie B2B SaaS skierowane wyłącznie do klientów korporacyjnych, nigdy do użytkowników indywidualnych Outlook.com.
Zastrzeżenia
Użytkownicy z osobistymi kontami Microsoft otrzymają błąd. Dopuszczalna prostsza walidacja tokenu (wzorzec pojedynczego wystawcy).
konsumenci
Akceptuje
Tylko osobiste konta Microsoft (Outlook.com, Hotmail, Live).
Przypadek użycia
Aplikacje konsumenckie skierowane do skrzynek odbiorczych. Rzadkość w przypadku SaaS B2B.
Zastrzeżenia
Konta Microsoft 365 dla firm są odrzucane. Nieprzydatne dla modelu SaaS obsługującego użytkowników biznesowych.
/{identyfikator-dzierżawcy}
Akceptuje
Konta w określonym dzierżawcy Microsoft Entra.
Przypadek użycia
Narzędzia wewnętrzne dla jednego dzierżawcy (aplikacja własnej firmy). Przepływy zgody administratora skierowane do określonego dzierżawcy. Używane również we wzorcach adresów URL przekierowań zgody administratora.
Zastrzeżenia
Każdy inny użytkownik dzierżawcy jest odrzucany. Odpowiednie tylko dla aplikacji wewnętrznych lub gdy celowo ograniczamy dostęp do dzierżawcy jednego klienta.
Uwaga dotycząca walidacji tokenu dla /common: Gdy używasz
/wspólny końcowy punkt, ten Iść (upoważniający) roszczenie w JWT będzie https://login.microsoftonline.com/{tenantId}/v2.0 gdzie {tenantId} różni się w zależności od użytkownika. Skonfiguruj swoją bibliotekę walidacji JWT, aby akceptowała dowolny pasujący wystawcę https://login.microsoftonline.com/{tenantId}/v2.0 zamiast stałego ciągu nadawcy.Zakresy poczty
Zakresy poczty Microsoft Graph: Szczegółowy podział
Microsoft Graph używa zakresów uprawnień do kontrolowania tego, co może robić Twoja aplikacja. Zbyt wiele żądanych zakresów zwiększa tarcia na ekranie zgody i zmniejsza konwersję. Zbyt mało żądanych zakresów powoduje błędy w czasie wykonywania. Oto wszystkie zakresy poczty, które musisz znać.
| Zakres | Typ | Co umożliwia | Zgoda administratora? |
|---|---|---|---|
| Mail.Read | Delegowany | Przeczytaj wszystkie wiadomości w skrzynce pocztowej uwierzytelnionego użytkownika. Zawiera nagłówki, treść, załączniki. Tylko do odczytu – nie można modyfikować ani wysyłać. | Użytkownik |
| Mail.ReadBasic | Delegowany | Odczyt ograniczonej liczby właściwości wiadomości: temat, nadawca, odbiorcy, data. Nie można odczytać treści ani załączników wiadomości. Przydatne do lekkiego listowania skrzynki odbiorczej bez pełnego dostępu do treści. | Użytkownik |
| Mail.ReadWrite | Delegowany | Odczytuj i modyfikuj wszystkie wiadomości. Obejmuje tworzenie, aktualizowanie, usuwanie wiadomości i folderów. Nadzbiór Mail.Read - nie żądaj obu. | Użytkownik |
| Mail.Send | Delegowany | Wysyłaj wiadomości e-mail jako uwierzytelniony użytkownik. Wymagane, nawet jeśli masz również uprawnienia Mail.ReadWrite - wysyłanie jest osobnym uprawnieniem w Microsoft Graph. | Użytkownik |
| Mail.Read.Shared | Delegowany | Odczytywanie poczty w współdzielonych skrzynkach pocztowych lub skrzynkach pocztowych innych użytkowników, do których uwierzytelniony użytkownik otrzymał dostęp. Nie do odczytywania własnej skrzynki pocztowej użytkownika. | Użytkownik |
| Mail.ReadWrite.Shared | Delegowany | Odczytuj i modyfikuj wiadomości e-mail w współdzielonych skrzynkach pocztowych, do których użytkownik ma dostęp. | Użytkownik |
| Mail.Wyślij.Współdzielony | Delegowany | Wyślij e-mail z udostępnionych skrzynek pocztowych lub "Wyślij w imieniu" innego użytkownika (jeśli użytkownik udzielił dostępu). | Użytkownik |
| dostęp offline | Delegowany | Instruuje Microsoft, aby wydał token odświeżania. Bez niego otrzymujesz tylko krótko działający token dostępu, bez możliwości jego odnowienia. Zawsze wymagany dla aplikacji SaaS. | Użytkownik |
| openid | Delegowany | Zwraca token identyfikacyjny z podstawowymi danymi użytkownika. Wymagane, jeśli chcesz wiedzieć, kto się uwierzytelnił, bez wykonywania oddzielnego wywołania API /me. | Użytkownik |
| profil | Delegowany | Dodaje roszczenia name i preferred_username do tokenu ID. Zazwyczaj uwzględniane z openid. | Użytkownik |
| Mail.Odczyt (Aplikacja) | Zastosowanie | Odczytaj całą pocztę ze wszystkich skrzynek pocztowych w dzierżawie bez interakcji użytkownika. Używane przez usługi demona. Wymaga zgody administratora dzierżawy. | wymagany administrator |
| Mail.ReadWrite (Aplikacja) | Zastosowanie | Czytaj i zapisuj wszystkie wiadomości e-mail we wszystkich skrzynkach pocztowych najemców. Bardzo szerokie uprawnienia. Tylko dla zaufanych narzędzi wewnętrznych za wyraźną zgodą administratora najemcy. | wymagany administrator |
Mail.Read
Delegowany
Przeczytaj wszystkie wiadomości w skrzynce pocztowej uwierzytelnionego użytkownika. Zawiera nagłówki, treść, załączniki. Tylko do odczytu – nie można modyfikować ani wysyłać.
Mail.ReadBasic
Delegowany
Odczyt ograniczonej liczby właściwości wiadomości: temat, nadawca, odbiorcy, data. Nie można odczytać treści ani załączników wiadomości. Przydatne do lekkiego listowania skrzynki odbiorczej bez pełnego dostępu do treści.
Mail.ReadWrite
Delegowany
Odczytuj i modyfikuj wszystkie wiadomości. Obejmuje tworzenie, aktualizowanie, usuwanie wiadomości i folderów. Nadzbiór Mail.Read - nie żądaj obu.
Mail.Send
Delegowany
Wysyłaj wiadomości e-mail jako uwierzytelniony użytkownik. Wymagane, nawet jeśli masz również uprawnienia Mail.ReadWrite - wysyłanie jest osobnym uprawnieniem w Microsoft Graph.
Mail.Read.Shared
Delegowany
Odczytywanie poczty w współdzielonych skrzynkach pocztowych lub skrzynkach pocztowych innych użytkowników, do których uwierzytelniony użytkownik otrzymał dostęp. Nie do odczytywania własnej skrzynki pocztowej użytkownika.
Mail.ReadWrite.Shared
Delegowany
Odczytuj i modyfikuj wiadomości e-mail w współdzielonych skrzynkach pocztowych, do których użytkownik ma dostęp.
Mail.Wyślij.Współdzielony
Delegowany
Wyślij e-mail z udostępnionych skrzynek pocztowych lub "Wyślij w imieniu" innego użytkownika (jeśli użytkownik udzielił dostępu).
dostęp offline
Delegowany
Instruuje Microsoft, aby wydał token odświeżania. Bez niego otrzymujesz tylko krótko działający token dostępu, bez możliwości jego odnowienia. Zawsze wymagany dla aplikacji SaaS.
openid
Delegowany
Zwraca token identyfikacyjny z podstawowymi danymi użytkownika. Wymagane, jeśli chcesz wiedzieć, kto się uwierzytelnił, bez wykonywania oddzielnego wywołania API /me.
profil
Delegowany
Dodaje roszczenia name i preferred_username do tokenu ID. Zazwyczaj uwzględniane z openid.
Mail.Odczyt (Aplikacja)
Zastosowanie
Odczytaj całą pocztę ze wszystkich skrzynek pocztowych w dzierżawie bez interakcji użytkownika. Używane przez usługi demona. Wymaga zgody administratora dzierżawy.
Mail.ReadWrite (Aplikacja)
Zastosowanie
Czytaj i zapisuj wszystkie wiadomości e-mail we wszystkich skrzynkach pocztowych najemców. Bardzo szerokie uprawnienia. Tylko dla zaufanych narzędzi wewnętrznych za wyraźną zgodą administratora najemcy.
Minimalny zakres: czytnik skrzynki odbiorczej
zakres=Mail.Readdostęp_offlineopenidprofil
Odczytuj wiadomości, odświeżaj tokeny, tożsamość użytkownika. Bez możliwości zapisu lub wysyłania.
Standardowy zakres: pełna integracja z pocztą e-mail
zakres=Mail.ReadWriteMail.Senddostęp_offlineopenidprofil
Czytaj, pisz, wysyłaj. Najczęstszy zestaw do integracji CRM i narzędzi sprzedażowych.
Model uprawnień
Uprawnienia Delegowane a Uprawnienia Aplikacji: Kiedy Stosować Każde z Nich
Microsoft Graph wykorzystuje dwa zasadniczo różne modele uprawnień. Większość deweloperów SaaS domyślnie wybiera niewłaściwy, co prowadzi do niepotrzebnych wymagań zgody administratora i wadliwego doświadczenia użytkownika. Oto dokładnie, kiedy należy używać każdego z nich.
Uprawnienia delegowane
Działaj w imieniu zalogowanego użytkownika
Aplikacja uzyskuje dostęp do Microsoft Graph przy użyciu tożsamości uwierzytelnionego użytkownika. Aplikacja może wykonywać tylko te czynności, które mógłby wykonać sam użytkownik. Jeśli użytkownik nie może odczytać folderu, Twoja aplikacja również nie może.
Użytkownik wyraża zgodę podczas przepływu OAuth - administrator nie jest wymagany dla standardowych zakresów
Dostęp jest ograniczony do skrzynki pocztowej każdego użytkownika.
Użytkownicy mogą w każdej chwili cofnąć dostęp w ustawieniach swojego konta Microsoft
Respektuje uprawnienia na poziomie użytkownika, przypisania ról i zasady dostępu do skrzynki pocztowej
Użyj tego do aplikacji SaaS, w których każdy użytkownik uwierzytelnia się indywidualnie
Uprawnienia aplikacji
Zachowuj się jak sama aplikacja
Aplikacja uzyskuje dostęp do Microsoft Graph bez obecności użytkownika. Używane w usługach w tle, demonach i zautomatyzowanych przepływach pracy. Aplikacja uwierzytelnia się przy użyciu własnych poświadczeń (przepływ poświadczeń klienta).
Wymaga zgody administratora najemcy – znacząca przeszkoda dla użytkowników zewnętrznych
Dostęp jest w ramach całej dzierżawy - można odczytać WSZYSTKIE skrzynki pocztowe po wyrażeniu zgody przez administratora
Nie wymaga logowania interaktywnego użytkownika – działa dla automatyki bezobsługowej
Nadaje się do wewnętrznych narzędzi IT, w których administratorzy Twojej organizacji kontrolują wdrożenie
Wyłącznie do użytku wewnętrznego narzędzi, gdzie administrator Twojej organizacji udziela pełnego dostępu do dzierżawy
Zasada decyzyjna SaaS
Jeśli budujesz produkt używany przez klientów zewnętrznych kto loguje się indywidualnie, użyj Uprawnienia delegowane. Każdy klient uwierzytelnia się za pomocą własnego konta Microsoft, wyraża zgodę na zakresy Twojej aplikacji, a Twoja aplikacja działa w imieniu uwierzytelnionego użytkownika. Uprawnienia aplikacji wymagają od administratora dzierżawy wstępnego zatwierdzenia aplikacji dla całej ich organizacji – co jest krokiem zabijającym konwersję w lejku samoobsługowym SaaS. Jedynym wyjątkiem jest sytuacja, gdy tworzysz wewnętrzne narzędzie dla przedsiębiorstwa wdrażane przez własny zespół IT w swojej własnej dzierżawie.
Pełne przejście
Auth Code + PKCE: Przykłady krok po kroku w Curl
Oto kompletny przepływ kodu autoryzacji OAuth 2.0 Microsoft Graph z PKCE, od generowania kodu weryfikującego do wymiany tokenów. Są to przykłady na poziomie produkcyjnym, które można bezpośrednio dostosować do stosu technologicznego.
Krok 1 z 4 - Generowanie parametrów PKCE
Wygeneruj code_verifier i code_challenge
PKCE działa poprzez generowanie losowego sekretu (code_verifier), a następnie skrótu SHA-256 z niego (code_challenge). Wysyłasz wyzwanie (challenge) w kroku 2, a weryfikator (verifier) w kroku 4. Microsoft weryfikuje ich zgodność, zapobiegając przechwyceniu kodu.
import os, base64, hashlib
# 1. Wygeneruj code_verifier (43–128 znaków, kod base64 bezpieczny dla adresów URL)
code_verifier = base64.urlsafe_b64encode(
Myślę, że chodzi Ci o skrót "os.". Jeśli tak, to na język polski możemy go przetłumaczyć na kilka sposobów, w zależności od kontekstu:
* **Osoba** (np. w spisie rzeczy: "os. do kontaktu" - osoba do kontaktu)
* **Okręt podwodny** (w kontekście wojskowym)
* **Oś** (w kontekście technicznym lub geometrycznym)
Bez dodatkowego kontekstu trudno mi podać dokładne tłumaczenie.urandom(32)
).dekoduj('utf-8').rstrip('=')
# 2. Wygeneruj code_challenge = BASE64URL(SHA256(code_verifier))
wyzwanie_kodowania = base64.urlsafe_b64encode(
hashlib.sha256(kod_weryfikacyjny.koduj('utf-8')).streszczenie()
).dekoduj('utf-8').rstrip('=')
# Zapisz code_verifier w sesji – będzie potrzebny w kroku 4
# Prześlij kod_challenge w adresie URL autoryzacjiKrok 2 z 4 - Żądanie autoryzacji
Zbuduj adres URL /authorize i przekieruj użytkownika
Przekieruj przeglądarkę użytkownika do punktu końcowego autoryzacji firmy Microsoft. Użytkownik widzi stronę logowania firmy Microsoft, uwierzytelnia się i wyraża zgodę na zakresy Twojej aplikacji. Następnie firma Microsoft przekierowuje z powrotem do Twojego `redirect_uri` z kodem autoryzacyjnym.
client_id
Identyfikator aplikacji (klienta) z rejestracji aplikacji Entra
typ_odpowiedzi
kod - żąda kodu autoryzacyjnegoprzekierowanie_uri
Musi dokładnie odpowiadać identyfikatorowi URI zarejestrowanemu w aplikacji Entra. Zakodowane w adresie URL.
zakres
Lista rozdzielana spacjami. Zawsze dołącz
dostęp offline dla tokenów odświeżania.stan
Nieprzezroczysta wartość, którą generujesz. Zwrócona niezmieniona w funkcji zwrotnej. Użyj jej do zapobiegania CSRF i przywracania stanu interfejsu użytkownika.
wyzwanie_kodowania
Wartość BASE64URL(SHA256(code_verifier)) z kroku 1.
metoda_wyzwania_kodowego
S256 - zawsze używaj SHA-256, nigdy czysty# Utwórz adres URL autoryzacji (format ułatwiający czytanie)
AUTH_URL="https://login.microsoftonline.com/common/oauth2/v2.0/authorize
?client_id=TWÓJ_CLIENT_ID
&typ_odpowiedzi=kod
&redirect;_uri=https://app.com/auth/ms/cb
&scope;=Mail.ReadWriteMail.Sendoffline_access
&stan=LOSOWA_WARTOSC_STANU
&challenge_kod=TWÓJ_CODE_CHALLENGE
&code_challenge_method=S256"
# Przekieruj użytkownika na adres $AUTH_URL
# Microsoft obsługuje logowanie, uwierzytelnianie wieloskładnikowe (MFA) oraz ekran zgody
# W przypadku powodzenia: redirect_uri?code=AUTH_CODE&state;=...Krok 3 z 4 - Obsługa powiadomienia zwrotnego
Odbierz kod autoryzacyjny na swoim adresie redirect_uri
Microsoft przekierowuje do twojego redirect_uri z
kod parametr zapytania. Zweryfikuj stan Parametr pasuje do tego, co wysłałeś. Kod wygasa za 10 minut – wymień go natychmiast w kroku 4.Krok 4 z 4 - Wymiana tokenów
Wymień kod autoryzacyjny na tokeny dostępu + odświeżania
Wyślij POST do punktu końcowego tokenu z kodem autoryzacyjnym i swoją wartością code_verifier. Microsoft zwróci token dostępu (ważny przez około 60-90 minut) oraz token odświeżania (długoterminowy). Przechowaj oba bezpiecznie.
Kod autoryzacyjny platformy # dla tokenów
curl -X POST "https://login.microsoftonline.com/common/oauth2/v2.0/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=TWÓJ_CLIENT_ID" \
-d "client_secret=TWÓJ_CLIENT_SECRET" \
-d "typ_dostępu=kod_autoryzacyjny" \
-d "kod=AUTORYZACJA_Z_POWIADOMIENIA" \
-d "redirect_uri=https://app.com/auth/ms/cb" \
-d "code_verifier=TWÓJ_CODE_VERIFIER" \
-d "scope=Mail.ReadWrite Mail.Send offline_access"
Zwraca: access_token, refresh_token, expires_in, scope
{
"typ_tokenu": "Posiadacz",
"zakres": "Mail.ReadWrite Mail.Send offline_access",
"ważny_przez": 3600,
"token dostępu": "eyJ0eXAiOiJKV1Qi...",
"token_odświeżający": "0.ARoAi7W...",
"id_token": "eyJ0eXAi..."
}Cykl życia tokena
Obsługa tokenów odświeżania: rotacja, wygaśnięcie i dostęp warunkowy
Tokeny odświeżania Microsoft Graph są długożyjące, ale nie stałe. Kilka warunków może je cicho unieważnić. Zrozumienie tych przypadków brzegowych odróżnia produkcyjną integrację Microsoft OAuth od tej, która losowo psuje się u użytkowników korporacyjnych.
Wygaśnięcie po 90 dniach nieaktywności
Tokeny odświeżania Microsoft wygasają po 90 dniach braku aktywności. Jeśli użytkownik nie korzysta z Twojej aplikacji przez 90 dni, jego token odświeżania staje się nieważny i musi on ponownie uwierzytelnić się. Nie ma sposobu, aby przedłużyć ten okres bez interakcji użytkownika. Zawsze obsługuj
nieprawidłowe_poświadczenie obsłużyć błędy w sposób zgrabny i wyświetlić monit o ponowne uwierzytelnienie.Zmiany w zasadach dostępu warunkowego
Najemcy korporacyjni korzystają z zasad dostępu warunkowego (wymogi dotyczące MFA, zgodność urządzeń, ograniczenia lokalizacji). Jeśli zasada ulegnie zmianie po uwierzytelnieniu użytkownika, jego token odświeżania może zostać unieważniony przy następnym użyciu. Jest to decyzja po stronie klienta – nie możesz jej kontrolować ani przewidzieć. Zawsze przekazuj błędy uwierzytelniania użytkownikom z jasnym komunikatem o ponownym uwierzytelnieniu.
Rotacja tokenu odświeżającego
Podczas używania tokenu odświeżania do uzyskania nowego tokenu dostępu, Microsoft może wydać nowy token odświeżania. Zawsze zapisuj nowy token odświeżania z odpowiedzi, zastępując stary. Jeśli będziesz nadal używać starego tokenu odświeżania po jego rotacji, ostatecznie napotkasz
nieprawidłowe_poświadczenie błąd.Odwołanie administratora
Administrator dzierżawy może w dowolnym momencie cofnąć wszystkie tokeny odświeżania dla użytkownika lub całej organizacji (np. gdy pracownik odchodzi lub w przypadku incydentu bezpieczeństwa). Twoja aplikacja otrzymuje
nieprawidłowe_poświadczenie. Jest to oczekiwane zachowanie - należy sobie z tym poradzić, oznaczając połączone konto jako wymagające ponownej autoryzacji.# Odśwież token dostępu przy użyciu zapisanego tokenu odświeżającego
curl -X POST "https://login.microsoftonline.com/common/oauth2/v2.0/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=TWÓJ_CLIENT_ID" \
-d "client_secret=TWÓJ_CLIENT_SECRET" \
-d "grant_type=refresh_token" \
-d "refresh_token=PRZECHOWYWANY_TOKEN_ODSWIEZAJACY" \
-d "scope=Mail.ReadWrite Mail.Send offline_access"
# Zawsze sprawdzaj, czy w odpowiedzi znajduje się nowy token odświeżający.
# Jeśli jest obecny, należy natychmiast wymienić go na nowy.
# Jeśli pojawi się błąd „invalid_grant”, poproś użytkownika o ponowne uwierzytelnienie.Rozwiązywanie problemów
Typowe błędy AADSTS z objaśnieniem
Błędy Microsoft Graph OAuth przestrzegają spójnego wzorca kodów błędów AADSTS. Oto najczęstsze z nich, które napotkasz podczas tworzenia aplikacji i w produkcji, wraz z dokładnymi przyczynami źródłowymi i poprawkami.
| Kod błędu | Co to oznacza | Przyczyna źródłowa i rozwiązanie |
|---|---|---|
| AADSTS65001 | Nie udzielono zgody na jeden lub więcej z żądanych zakresów | Użytkownik nie wyraził zgody na zakresy aplikacji lub administrator dzierżawy zablokował zgodę użytkownika na aplikację. Poprawka: Uwzględnij zgoda w swoim adresie URL autoryzacji, aby wymusić ponowne wyświetlenie ekranu zgody, lub wysłać adres URL zgody administratora do administratora dzierżawy.Dodaj monit = zgoda lub poproś o zgodę administratora |
| AADSTS50011 | Niezgodność URI przekierowania | The przekierowanie_uri żądanie nie pasuje dokładnie do żadnego zarejestrowanego URI przekierowania w rejestracji aplikacji Entra. Nawet różnica w znaku ukośnika na końcu powoduje ten błąd. Rozwiązanie: Skopiuj dokładny URI z rejestracji aplikacji Entra i użyj go dokładnie tak, jak został podany.Naprawiono: dokładne dopasowanie identyfikatora URI w rejestracji aplikacji Entra |
| AADSTS700016 | Aplikacja nie znaleziona w dzierżawie | The client_id nie istnieje w dzierżawie, wobec której następuje uwierzytelnianie. Częste podczas używania urzędu specyficznego dla dzierżawy (/{identyfikator-dzierżawcy}) dla aplikacji wielodostępnej. Poprawka: Użyj /wspólny lub /organizacje autorytet dla aplikacji wielodostępnych.Napraw: przełącz się na autorytet /common lub /organizations |
| AADSTS90099 | Aplikacja nie została autoryzowana w tym miejscu docelowym (wymagana zgoda) | Aplikacja istnieje, ale nie została zaakceptowana w dzierżawie użytkownika. Różni się od AADSTS65001 tym, że cała aplikacja jest zablokowana, a nie tylko określone zakresy. Rozwiązanie: Wyślij adres URL zgody administratora do administratora IT klienta. Poprawka: adres URL zgody administratora do administratora dzierżawy klienta |
| AADSTS70011 | Udzielony grant jest nieprawidłowy lub wygasł | Token odświeżania lub kod autoryzacji wygasł lub został unieważniony. Kody autoryzacji wygasają po 10 minutach. Tokeny odświeżania wygasają po 90 dniach nieaktywności lub unieważnieniu przez administratora. Naprawa: Poproś użytkownika o ponowne uwierzytelnienie od początku procesu OAuth. Poprawka: pełne ponowne uwierzytelnienie |
| AADSTS50076 | Wieloskładnikowe uwierzytelnianie jest wymagane przez zasady dostępu warunkowego | Wynajmujący użytkownika wymaga uwierzytelniania wieloskładnikowego dla Twojej aplikacji. Jest to decyzja po stronie klienta egzekwowana przez administratora wynajmującego. Twoja aplikacja nie może tego ominąć. Użytkownik musi ukończyć MFA. W przypadku używania przepływu kodu uwierzytelniającego, Microsoft automatycznie wyświetli monit MFA w przeglądarce. Problemy pojawiają się w zautomatyzowanych przepływach (poświadczenia klienta), które nie mogą ukończyć MFA. Oczekiwane: użytkownik musi ukończyć MFA |
| AADSTS50020 | Konto użytkownika z zewnętrznego dostawcy tożsamości nie istnieje w dzierżawie | Użytkownik próbuje uwierzytelnić się za pomocą osobistego konta Microsoft w dzierżawie, która zezwala tylko na konta organizacyjne, lub odwrotnie. Napraw: Sprawdź punkt końcowy autoryzacji – jeśli używasz /organizacje, konta osobiste nie mogą uwierzytelnić się. Przełącz się na /wspólny jeśli potrzebujesz obu.Poprawka: przełącz autorytet na /common |
| AADSTS53003 | Dostęp zablokowany przez zasadę dostępu warunkowego | Polityka dostępu warunkowego firmy zablokowała tę próbę uwierzytelnienia całkowicie (np. zablokowany kraj, niezarządzane urządzenie, zablokowana aplikacja). Jest to decyzja po stronie klienta. Nie można jej pominąć. Wyświetl błąd użytkownikowi i doradź mu skontaktowanie się z administratorem IT. Klient: proszę skontaktować się z administratorem IT |
Alternatywa dla Unipile
Pomiń 5 tygodni prac związanych z OAuth z Unipile
Wszystko w tym przewodniku – rejestracja aplikacji Entra, punkty końcowe autoryzacji, wybór zakresu, PKCE, rotacja tokenów, obsługa błędów AADSTS – to czas inżynieryjny, który nie przyspiesza rozwoju Twojego produktu. Unipile obsługuje cały stos Microsoft Graph OAuth jako usługę zarządzaną, dzięki czemu Twój zespół pisze jedno wywołanie API zamiast 500 linii kodu związanego z OAuth.
Zbudowanie tego samemu
Rejestracja i konfiguracja aplikacji Entra
Implementacja PKCE i generowanie wyzwań kodowych
Przechowywanie tokenów odświeżania, obracanie i obsługa wygasania
Przepływ zgody administratora dla klientów korporacyjnych
Obsługa błędów AADSTS i monit o ponowne uwierzytelnienie
Rotacja klucza tajnego klienta przed wygaśnięciem
Obsługa zastrzeżeń dotyczących dostępu warunkowego w przeliczeniu na dzierżawcę
Rozdzielone stosy OAuth dla Gmaila i dostawców IMAP
Korzystanie z Unipile
Jeden POST do wygenerowania linku uwierzytelniającego hostowanego
Unipile automatycznie zarządza PKCE, tokenami i odświeżaniem
Tokeny nigdy nie są przechowywane w naszej bazie danych - Unipile się tym zajmuje
Ta sama platforma API dla kont Microsoft, Gmail i IMAP
Powiadomienia przez webhook, gdy konta wymagają ponownej autoryzacji
Branded screen zgody z własnymi poświadczeniami aplikacji Entra
Dostarcz swoją integrację poczty e-mail w kilka godzin, a nie tygodni.
Jak działa Microsoft OAuth w Unipile
Twoje zaplecze wywołuje jeden punkt końcowy w celu wygenerowania linku do uwierzytelniania. Twój użytkownik klika go, uwierzytelnia się za pomocą Microsoft, a Unipile zarządza całym przepływem OAuth – przekierowaniem Entra, obsługą zakresu, wymianą tokenów i odświeżaniem. Połączone konto jest następnie dostępne za pośrednictwem ujednoliconego API poczty e-mail firmy Unipile.
import żądania
UNIPILE_API_URL = "https://apiXXX.unipile.com:XXX"
UNIPILE_API_KEY = "your-api-key"
# Krok 1: Wygeneruj link do uwierzytelniania w chmurze dla Microsoftu
response = requests.stanowisko(
f"{UNIPILE_API_URL}/api/v1/hosted/accounts/link",
nagłówki={
"X-API-KEY": UNIPILE_API_KEY,
"Content-Type": "application/json"
},
json={
"typ": "create",
"dostawcy": ["MICROSOFT"],
"api_url": URL_UNIPILE_API,
"ważne do": "2026-12-31T23:59:59Z",
# Opcjonalnie: przypisz ten link do konkretnego użytkownika
"name": "id_uzytkownika_123",
# Opcjonalnie: otrzymuj powiadomienia o połączeniu konta
"adres_powiadomienia": "https://app.yourproduct.com/webhooks/account-linked"
}
)
# Krok 2: Przekieruj użytkownika na ten adres URL
hosted_auth_url = odzew.json()["url"]
Przykład #: https://account.unipile.com/[encoded-token]
# Unipile obsługuje: przekierowanie Entra, ekran zgody, PKCE,
Wymiana tokenów #, odświeżanie pamięci tokenów, zarządzanie zakresem
# Krok 3: Po uwierzytelnieniu skorzystaj z interfejsu API poczty elektronicznej Unipile, aby odczytywać/wysyłać wiadomości
emails = wnioski.uzyskać(
f"{UNIPILE_API_URL}/api/v1/emails",
nagłówki={"X-API-KEY": {UNIPILE_API_KEY},
parametry={"account_id": "identyfikator-powiązanego-konta"}
)Microsoft OAuth zakończone. Skrzynka pocztowa dostępna poprzez zunifikowane API.
Przepływ uwierzytelniania hostowanego
Unipile hostuje ekran zgody OAuth. Twoi użytkownicy widzą czysty, oznakowany przepływ. Bez konieczności utrzymywania adresów URI przekierowania, problemów z CORS, żonglowania adresami URL między lokalnym hostem a produkcyjnym.
Zarządzanie tokenami
Unipile przechowuje i obraca tokeny Microsoft OAuth w Twoim imieniu. Rotacja tokenów odświeżania, monitorowanie 90-dniowej nieaktywności i powiadomienia o ponownym uwierzytelnieniu są obsługiwane automatycznie.
Zunifikowane API poczty e-mail
Po połączeniu skrzynki pocztowe Microsoft, Gmail i IMAP odpowiadają na te same punkty końcowe poczty e-mail Unipile. Jedna integracja obsługuje wszystkich trzech dostawców.
Twoje własne poświadczenia Entra
Skonfiguruj własne dane uwierzytelniające aplikacji Microsoft Entra w panelu Unipile. Twoi użytkownicy zobaczą nazwę Twojej aplikacji na ekranie zgody firmy Microsoft, a nie firmy Unipile.
Powiadomienia webhook
Odbieraj webhooki, gdy połączone konto wymaga ponownej autoryzacji (wygaśnięty token odświeżania, cofnięcie uprawnień przez administratora, zmiana Warunkowego Dostępu). Natychmiast wyświetl monit o ponowną autoryzację w swoim produkcie.
Czytaj, wysyłaj i synchronizuj
Po uwierzytelnieniu Microsoft OAuth poprzez Unipile, możesz odczytywać wiadomości e-mail, wysyłać wiadomości e-mail, synchronizować wątki, zarządzać folderami i obsługiwać załączniki – wszystko za pośrednictwem zunifikowanego API poczty e-mail Unipile. Nie jest potrzebny osobny klient Microsoft Graph.
Jak działa Unipile
Unipile jest niezależnym pośrednikiem technicznym, który działa w imieniu każdego uwierzytelnionego użytkownika za pośrednictwem tokenów OAuth wydanych przez Microsoft. Kiedy użytkownik połączy swoją skrzynkę pocztową Outlook lub Microsoft 365, Unipile działa wyłącznie z wykorzystaniem delegowanych uprawnień tego użytkownika. Unipile nie jest powiązany, wspierany ani sponsorowany przez firmę Microsoft. Korzystamy z publicznego interfejsu API Microsoft Graph w imieniu uwierzytelnionych użytkowników końcowych. Każde konto działa w ramach własnej tożsamości Microsoft Entra użytkownika i zasad dostępu warunkowego jego organizacji.
FAQ
Często zadawane pytania
Najczęstsze pytania dotyczące OAuth w Microsoft Graph w zakresie integracji poczty e-mail, od wyboru zakresów, przez cykl życia tokenów, po przepływy zgody przedsiębiorstwa.
01
Czy Microsoft Graph OAuth działa zarówno dla kont Outlook.com, jak i Microsoft 365?
Tak. Używanie
/wspólny endpointu autoryzacji, pojedyncza rejestracja aplikacji Microsoft Entra obsługuje uwierzytelnianie zarówno dla osobistych kont Outlook.com, jak i dla kont służbowych/szkolnych Microsoft 365. Kluczowe jest wybranie opcji "Konta w dowolnym katalogu organizacji oraz osobiste konta Microsoft" podczas rejestrowania aplikacji w portalu Azure.02
Gdy użytkownik opuszcza firmę, jego tokeny OAuth są unieważniane.
Kiedy administrator IT wyłączy lub usunie konto użytkownika w Microsoft Entra ID, wszystkie tokeny odświeżające tego użytkownika są natychmiast unieważniane. Twoja następna próba odświeżenia tokenu zwraca błąd
nieprawidłowe_poświadczenie Błąd. Obsłuż to w sposób płynny: oznacz powiązane konto jako wymagające ponownego uwierzytelnienia i wyświetl wyraźny monit o ponowne uwierzytelnienie w swoim produkcie. Jest to oczekiwane zachowanie – decyzja po stronie klienta, niezależna od Ciebie.03
Czy zgoda administratora jest wymagana do odczytu wiadomości e-mail programu Outlook za pośrednictwem protokołu Microsoft Graph OAuth?
Nie, w przypadku standardowych uprawnień delegowanych.
Mail.Read, Mail.ReadWriteoraz Mail.Send zakresy zgody użytkownika - poszczególni użytkownicy mogą je zatwierdzać podczas przepływu OAuth. Zgoda administratora jest wymagana tylko dla uprawnień aplikacji lub zakresów o wysokich uprawnieniach, takich jak Użytkownik.Odczyt.Wszystkie. Niektórzy administratorzy dzierżawców firmowych konfigurują zasady blokujące zgodę na wszystkie aplikacje innych firm – jest to decyzja po stronie klienta.04
Jak długo trwają tokeny odświeżania w usłudze Microsoft Graph?
Tokeny odświeżające wygasają po 90 dniach braku aktywności. Dopóki Twoja aplikacja regularnie korzysta z tokena odświeżającego (co dzieje się automatycznie podczas odświeżania tokenów dostępu przed ich wygaśnięciem co 60-90 minut), token odświeżający pozostaje aktywny. Zmiany w zasadach dostępu warunkowego, resetowanie haseł lub odwołanie przez administratora mogą unieważnić je wcześniej. Zawsze obsługuj
nieprawidłowe_poświadczenie błędy i zastąp stare tokeny odświeżające nowym zwróconym w każdej odpowiedzi tokenu.05
Jaka jest różnica między AADSTS65001 a AADSTS90099?
AADSTS65001: Użytkownik nie wyraził jeszcze zgody na jeden lub więcej określonych zakresów. Napraw: dodaj
zgoda do twojego adresu URL autoryzacji, aby wymusić ponowne wyświetlenie ekranu zgody. AADSTS90099: Cała aplikacja nie została autoryzowana w tym tenancie – administrator tenanta musi wstępnie zatwierdzić Twoją aplikację. Wyślij adres URL zgody administratora do administratora IT klienta. Oba błędy są częste w scenariuszach korporacyjnych, w których tenanci ograniczają zgodę użytkownika.06
Czy mogę użyć tej samej rejestracji aplikacji Entra do odczytu i wysyłania wiadomości e-mail?
Tak. Poproszę oba
Mail.ReadWrite oraz Mail.Send w tym samym zakresie. Ciąg znaków. Zauważ, że Mail.ReadWrite oraz Mail.Send to osobne zakresy - posiadanie uprawnienia do odczytu/zapisu nie przyznaje automatycznie uprawnienia do wysyłania. Zawsze uwzględniaj dostęp offline aby upewnić się, że otrzymasz token odświeżający. Zobacz strona API poczty elektronicznej szczegółów implementacyjnych.07
Czy Unipile przechowuje tokeny Microsoft OAuth w mojej bazie danych?
Nie. Kiedy korzystasz z hostowanego przepływu uwierzytelniania Microsoft firmy Unipile, Unipile zarządza wszystkimi tokenami OAuth w Twoim imieniu. Twoja aplikacja nigdy nie obsługuje bezpośrednio tokenów dostępu ani odświeżania tokenów Microsoft. Z połączonymi kontami można wchodzić w interakcję wyłącznie za pośrednictwem ujednoliconego interfejsu API poczty e-mail Unipile, używając klucza API Unipile. Eliminuje to wymogi dotyczące przechowywania, rotacji i bezpieczeństwa tokenów we własnej infrastrukturze.
08
Czy Unipile jest powiązane z Microsoftem?
Nie. Unipile nie jest powiązany, wspierany ani sponsorowany przez firmę Microsoft. Unipile jest niezależnym pośrednikiem technicznym, który korzysta z publicznego interfejsu API Microsoft Graph w imieniu uwierzytelnionych użytkowników końcowych. Każda integracja działa za pośrednictwem tokenów OAuth wydanych przez firmę Microsoft w ramach tożsamości użytkownika i zasad dostępu warunkowego jego organizacji. Microsoft Graph i Microsoft Entra są znakami towarowymi firmy Microsoft Corporation.
Masz jeszcze jakieś pytania? Nasz zespół może przeprowadzić Cię przez proces uzyskiwania dostępu OAuth do Microsoft Graph dla Twojego konkretnego przypadku użycia.
PL 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
TR