Buduj teraz

Microsoft Graph OAuth: Uwierzytelnianie skrzynek pocztowych Outlook i Microsoft 365 (Przewodnik 2026)

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.

Zbuduj to z Unipile Przewodnik po MS Graph
polaczenie_konta_outlook.py
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żeniem
Obsł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
Rozpocznij tworzenie przepływu Microsoft OAuth
Unipile - Rejestracja aplikacji Microsoft Entra
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, profil
Do odczytu + wysyłki
Mail.ReadWrite, Mail.Send, dostęp offline, openid, profil
dostę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.
Pomiń konfigurację: Zbuduj z Unipile zamiast tego
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ć.
Zgoda użytkownika
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.
Zgoda użytkownika
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.
Zgoda użytkownika
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.
Zgoda użytkownika
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.
Zgoda 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.
Zgoda użytkownika
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).
Zgoda użytkownika
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.
Zgoda użytkownika
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.
Zgoda użytkownika
profil Delegowany
Dodaje roszczenia name i preferred_username do tokenu ID. Zazwyczaj uwzględniane z openid.
Zgoda użytkownika
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
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.
Zobacz pełny przewodnik po API poczty e-mail
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.
pkce_wygeneruj.py
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 autoryzacji
Krok 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 autoryzacyjnego
przekierowanie_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
authorize_url.sh
# 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.
token_exchange.sh
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
token_response.json
{ "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.
odswiez_token.sh
# 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
Niech Unipile zajmie się tym wszystkim za Ciebie
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.
unipile_microsoft_oauth.py
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.
Rozpocznij tworzenie przepływu Microsoft OAuth Przewodnik po poczcie e-mail MS Graph
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_PLPL
en_USEN fr_FRFR es_ESES de_DEDE it_ITIT pt_BRBR nl_NLNL tr_TRTR pl_PLPL