Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
System uwierzytelniania zapasowego Microsoft Entra zapewnia odporność aplikacjom korzystającym z obsługiwanych protokołów i przepływów. Aby uzyskać więcej informacji na temat zapasowego systemu uwierzytelniania, zapoznaj się z zapasowym systemem uwierzytelniania Microsoft Entra ID.
Wymagania aplikacji dotyczące ochrony
Aplikacje muszą komunikować się z obsługiwaną nazwą hosta dla danego środowiska platformy Azure i używać protokołów obsługiwanych obecnie przez system uwierzytelniania kopii zapasowych. Korzystanie z bibliotek uwierzytelniania, takich jak biblioteka Microsoft Authentication Library (MSAL), gwarantuje, że używasz protokołów uwierzytelniania obsługiwanych przez system uwierzytelniania kopii zapasowych.
Nazwy hostów obsługiwane przez system uwierzytelniania kopii zapasowych
| Środowisko platformy Azure | Obsługiwana nazwa hosta |
|---|---|
| Azure Komercyjny | login.microsoftonline.com |
| Azure Government | login.microsoftonline.us |
Protokoły uwierzytelniania obsługiwane przez system uwierzytelniania kopii zapasowych
OAuth 2.0 i OpenID Connect (OIDC)
Typowe wskazówki
Wszystkie aplikacje korzystające z protokołów Open Authorization (OAuth) 2.0 lub OIDC powinny być zgodne z następującymi rozwiązaniami, aby zapewnić odporność:
- Aplikacja używa biblioteki MSAL lub ściśle przestrzega specyfikacji openID Connect i OAuth2. Firma Microsoft zaleca używanie bibliotek MSAL odpowiednich dla twojej platformy i przypadku użycia. Korzystanie z tych bibliotek zapewnia, że interfejsy API i wzorce wywołań są kompatybilne z systemem uwierzytelniania zapasowego.
- Aplikacja używa stałego zestawu zakresów zamiast dynamicznej zgody podczas uzyskiwania tokenów dostępu.
- Aplikacja nie używa Grantu Poświadczeń Hasła Właściciela Zasobu. Ten typ udzielania nie będzie obsługiwany przez system uwierzytelniania kopii zapasowych dla dowolnego typu klienta. Firma Microsoft zdecydowanie zaleca przejście do alternatywnych przepływów udzielania w celu uzyskania lepszych zabezpieczeń i odporności.
- Aplikacja nie korzysta z punktu końcowego UserInfo. Zmiana na użycie tokenu ID zmniejsza opóźnienie przez wyeliminowanie do dwóch żądań sieciowych oraz wykorzystanie istniejącego wsparcia dla odporności tokenu ID w systemie zapasowego uwierzytelniania.
Aplikacje natywne
Aplikacje natywne to publiczne aplikacje klienckie, które działają bezpośrednio na komputerach lub urządzeniach przenośnych, a nie w przeglądarce internetowej. Są one zarejestrowane jako klienci publiczni w rejestracji aplikacji w centrum administracyjnym firmy Microsoft Entra lub w witrynie Azure Portal.
Aplikacje natywne są chronione przez system uwierzytelniania kopii zapasowych, gdy spełnione są wszystkie następujące warunki:
- Aplikacja utrzymuje pamięć podręczną tokenu przez co najmniej trzy dni. Aplikacje powinny używać lokalizacji pamięci podręcznej tokenu urządzenia lub interfejsu API serializacji pamięci podręcznej tokenu, aby zachować pamięć podręczną tokenu nawet wtedy, gdy użytkownik zamknie aplikację.
- Aplikacja korzysta z interfejsu API AcquireTokenSilent biblioteki MSAL do pobierania tokenów przy użyciu buforowanych tokenów odświeżania. Użycie interfejsu API AcquireTokenInteractive może nie uzyskać tokenu z systemu uwierzytelniania kopii zapasowej, jeśli jest wymagana interakcja użytkownika.
System uwierzytelniania kopii zapasowej obecnie nie obsługuje mechanizmu autoryzacji urządzenia.
Jednostronicowe aplikacje internetowe
Aplikacje jednostronicowe (SPA) mają ograniczoną obsługę w systemie uwierzytelniania zapasowego. Aplikacje jednokartkowe (SPA), które korzystają z niejawnego przepływu autoryzacji i żądają tylko tokenów identyfikacyjnych OpenID Connect, są chronione. Tylko aplikacje, które używają MSAL.js 1.x lub bezpośrednio implementują przepływ niejawny, mogą korzystać z tej ochrony, ponieważ MSAL.js 2.x nie obsługuje przepływu niejawnego.
System uwierzytelniania zapasowego nie obsługuje obecnie przepływu kodu autoryzacyjnego z Proof Key for Code Exchange.
Aplikacje i usługi sieci Web
System uwierzytelniania kopii zapasowych nie obsługuje obecnie aplikacji internetowych i usług skonfigurowanych jako poufne klientów. Ochrona przepływu przyznawania kodu autoryzacyjnego i pozyskiwanie tokenów przy użyciu tokenów odświeżania oraz tajnych informacji klienta lub poświadczeń certyfikatu nie jest obecnie obsługiwana. Przepływ OAuth 2.0 typu "w imieniu" nie jest obecnie obsługiwany.
Logowanie jednokrotne SAML 2.0
Zapasowy system uwierzytelniania częściowo obsługuje protokół logowania jednokrotnego Security Assertion Markup Language (SAML) 2.0. Przepływy korzystające z przepływu inicjowanego przez dostawcę tożsamości SAML 2.0 są chronione przez zapasowy system uwierzytelniania. Aplikacje korzystające z przepływu zainicjowanego przez dostawcę usług (SP) nie są obecnie chronione przez system uwierzytelniania kopii zapasowych.
Protokoły uwierzytelniania tożsamości obciążeń wspierane przez system zapasowego uwierzytelniania
Protokół OAuth 2.0
Tożsamość zarządzana
Aplikacje korzystające z tożsamości zarządzanych do uzyskiwania tokenów dostępu firmy Microsoft są chronione. Firma Microsoft zaleca korzystanie z tożsamości zarządzanych przypisanych przez użytkownika w większości scenariuszy. Ta ochrona dotyczy zarówno tożsamości zarządzanych przypisanych przez użytkownika, jak i przez system.
Jednostka usługi
System uwierzytelniania zapasowego nie obsługuje obecnie uwierzytelniania tożsamości zadania opartego na tożsamości jednostki usługi przy użyciu przepływu udzielania poświadczeń klienta. Firma Microsoft zaleca korzystanie z wersji biblioteki MSAL odpowiedniej dla danej platformy, aby aplikacja była chroniona przez system uwierzytelniania awaryjnego, gdy ochrona będzie dostępna.