Platforma tożsamości Microsoft najlepszych rozwiązań i zaleceń

W tym artykule opisano najlepsze rozwiązania, zalecenia i typowe nadzoru podczas integracji z Platforma tożsamości Microsoft. Ta lista kontrolna przeprowadzi Cię przez proces wysokiej jakości i bezpiecznej integracji. Zapoznaj się z tą listą regularnie, aby upewnić się, że utrzymujesz jakość i bezpieczeństwo integracji aplikacji z platformą tożsamości. Lista kontrolna nie jest przeznaczona do przeglądania całej aplikacji. Zawartość listy kontrolnej może ulec zmianie w miarę wprowadzania ulepszeń platformy.

Jeśli dopiero zaczynasz, zapoznaj się z dokumentacją Platforma tożsamości Microsoft, aby dowiedzieć się więcej o podstawach uwierzytelniania, scenariuszach aplikacji w Platforma tożsamości Microsoft i nie tylko.

Użyj poniższej listy kontrolnej, aby upewnić się, że aplikacja jest skutecznie zintegrowana z Platforma tożsamości Microsoft.

Napiwek

Asystent integracji może pomóc w zastosowaniu wielu z tych najlepszych rozwiązań i zaleceń. Wybierz dowolną rejestrację aplikacji, a następnie wybierz element menu Asystent integracji, aby rozpocząć pracę z asystentem.

Podstawy

Przeczytaj i zapoznaj się z zasadami platformy Microsoft. Upewnij się, że aplikacja jest zgodna z warunkami opisanymi w celu ochrony użytkowników i platformy.

Własność

Upewnij się, że informacje skojarzone z kontem użytym do rejestrowania aplikacji i zarządzania nimi są aktualne.

Marka

Przestrzegaj wytycznych dotyczących znakowania dla aplikacji.

Podaj zrozumiałą nazwę i logo aplikacji. Te informacje są wyświetlane w monicie zgody aplikacji. Upewnij się, że Twoje imię i nazwisko i logo są reprezentatywne dla twojej firmy/produktu, aby użytkownicy mogli podejmować świadome decyzje. Upewnij się, że nie naruszasz żadnych znaków towarowych.

Prywatność

Podaj linki do warunków użytkowania aplikacji i zasad zachowania poufności informacji.

Zabezpieczenia

Zarządzanie identyfikatorami URI przekierowania:

• Zachowaj własność wszystkich identyfikatorów URI przekierowania i zachowaj dla nich aktualne rekordy DNS.
• Nie używaj symboli wieloznacznych (*) w identyfikatorach URI.
• W przypadku aplikacji internetowych upewnij się, że wszystkie identyfikatory URI są bezpieczne i szyfrowane (na przykład przy użyciu schematów https).
• W przypadku klientów publicznych użyj identyfikatorów URI przekierowania specyficznych dla platformy, jeśli ma to zastosowanie (głównie dla systemów iOS i Android). W przeciwnym razie użyj identyfikatorów URI przekierowania z dużą ilością losowości, aby zapobiec kolizjom podczas wywoływania z powrotem do aplikacji.
• Jeśli aplikacja jest używana z izolowanego agenta internetowego, możesz użyć polecenia https://login.microsoftonline.com/common/oauth2/nativeclient.
• Regularnie sprawdzaj i przycinaj wszystkie nieużywane lub niepotrzebne identyfikatory URI przekierowania.

Jeśli aplikacja jest zarejestrowana w katalogu, zminimalizuj i ręcznie monitoruj listę właścicieli rejestracji aplikacji.

Nie włączaj obsługi niejawnego przepływu udzielania OAuth2, chyba że jest to jawnie wymagane. Dowiedz się więcej o prawidłowym scenariuszu tutaj.

Przejście poza nazwę użytkownika/hasło. Nie używaj przepływu poświadczeń hasła właściciela zasobu (ROPC), który bezpośrednio obsługuje hasła użytkowników. Ten przepływ wymaga wysokiego stopnia zaufania i ujawnienia użytkowników i powinien być używany tylko wtedy, gdy nie można używać innych, bezpieczniejszych przepływów. Ten przepływ jest nadal potrzebny w niektórych scenariuszach (takich jak DevOps), ale należy pamiętać, że użycie go spowoduje nałożenie ograniczeń na aplikację. Aby uzyskać bardziej nowoczesne podejścia, przeczytaj scenariusze uwierzytelniania i aplikacji.

Ochrona poświadczeń aplikacji poufnych i zarządzanie nimi dla aplikacji internetowych, internetowych interfejsów API i aplikacji demona. Użyj poświadczeń certyfikatu, a nie poświadczeń hasła (wpisów tajnych klienta). Jeśli musisz użyć poświadczeń hasła, nie należy ustawiać go ręcznie. Nie przechowuj poświadczeń w kodzie lub konfiguracji i nigdy nie zezwalaj na ich obsługę przez ludzi. Jeśli to możliwe, użyj tożsamości zarządzanych dla zasobów platformy Azure lub usługi Azure Key Vault do przechowywania i regularnego obracania poświadczeń.

Upewnij się, że aplikacja żąda uprawnień najniższych uprawnień. Poproś tylko o uprawnienia, których aplikacja absolutnie potrzebuje, i tylko wtedy, gdy ich potrzebujesz. Zapoznaj się z różnymi typami uprawnień. W razie potrzeby używaj tylko uprawnień aplikacji; w miarę możliwości używaj delegowanych uprawnień. Aby uzyskać pełną listę uprawnień programu Microsoft Graph, zobacz tę dokumentację dotyczącą uprawnień.

Jeśli zabezpieczasz interfejs API przy użyciu Platforma tożsamości Microsoft, dokładnie zastanów się nad uprawnieniami, które powinien uwidocznić. Zastanów się, jaki jest odpowiedni stopień szczegółowości rozwiązania i które uprawnienia wymagają zgody administratora. Przed podjęciem jakichkolwiek decyzji dotyczących autoryzacji sprawdź oczekiwane uprawnienia w tokenach przychodzących.

Implementacja

Użyj nowoczesnych rozwiązań uwierzytelniania (OAuth 2.0, OpenID Connect), aby bezpiecznie logować użytkowników.

Nie programuj bezpośrednio względem protokołów, takich jak OAuth 2.0 i Open ID. Zamiast tego skorzystaj z biblioteki Microsoft Authentication Library (MSAL). Biblioteki MSAL bezpiecznie opakowuje protokoły zabezpieczeń w łatwej w użyciu bibliotece i zapewnia wbudowaną obsługę scenariuszy dostępu warunkowego, logowania jednokrotnego dla całego urządzenia i wbudowanej obsługi buforowania tokenów. Aby uzyskać więcej informacji, zobacz listę bibliotek klienckich obsługiwanych przez firmę Microsoft. Jeśli musisz ręcznie kodować protokoły uwierzytelniania, należy postępować zgodnie z metodologią programowania microsoft SDL lub podobną. Należy zwrócić szczególną uwagę na zagadnienia dotyczące zabezpieczeń w specyfikacji standardów dla każdego protokołu.

NIE należy patrzeć na wartość tokenu dostępu lub próbować przeanalizować ją jako klienta. Mogą zmieniać wartości, formaty, a nawet szyfrować bez ostrzeżenia — zawsze używaj tokenu identyfikatora, jeśli klient musi dowiedzieć się czegoś o użytkowniku. Tylko internetowe interfejsy API powinny analizować tokeny dostępu (ponieważ są to te, które definiują format i ustawiają klucze szyfrowania). Wysyłanie tokenu dostępu bezpośrednio do interfejsu API przez klienta jest zagrożeniem bezpieczeństwa, ponieważ są to poufne poświadczenia, które udzielają dostępu do niektórych zasobów. Deweloperzy nie powinni zakładać, że klient może być zaufany, aby zweryfikować token dostępu.

Migrowanie istniejących aplikacji z biblioteki Azure Active Directory Authentication Library (ADAL) do biblioteki Microsoft Authentication Library. Biblioteka MSAL to najnowsze rozwiązanie platformy tożsamości firmy Microsoft i jest dostępne na platformie .NET, JavaScript, Android, iOS, macOS, Python i Java. Przeczytaj więcej na temat migrowania aplikacji brokera ADAL.NET, ADAL.js i ADAL.NET i iOS.

W przypadku aplikacji mobilnych skonfiguruj każdą platformę przy użyciu środowiska rejestracji aplikacji. Aby aplikacja mogła korzystać z aplikacji Microsoft Authenticator lub Microsoft Portal firmy na potrzeby logowania jednokrotnego, aplikacja wymaga skonfigurowanego "identyfikatora URI przekierowania brokera". Dzięki temu firma Microsoft może wrócić kontrolę do aplikacji po uwierzytelnieniu. Podczas konfigurowania każdej platformy środowisko rejestracji aplikacji przeprowadzi Cię przez proces. Skorzystaj z przewodnika Szybki start, aby pobrać przykład roboczy. W systemie iOS użyj brokerów i systemowego widoku internetowego, jeśli jest to możliwe.

W aplikacjach internetowych lub internetowych interfejsach API zachowaj jedną pamięć podręczną tokenów na konto. W przypadku aplikacji internetowych pamięć podręczna tokenu powinna być kluczem identyfikatora konta. W przypadku internetowych interfejsów API konto powinno być kluczem skrótu tokenu używanego do wywoływania interfejsu API. MSAL.NET zapewnia serializacji niestandardowej pamięci podręcznej tokenów zarówno na platformie .NET, jak i w programie .NET Framework. Ze względów bezpieczeństwa i wydajności zalecamy serializacji jednej pamięci podręcznej na użytkownika. Aby uzyskać więcej informacji, przeczytaj o serializacji pamięci podręcznej tokenów.

Jeśli dane wymagane przez aplikację są dostępne za pośrednictwem programu Microsoft Graph, zażądaj uprawnień do tych danych przy użyciu punktu końcowego programu Microsoft Graph, a nie pojedynczego interfejsu API.

Środowisko użytkownika końcowego

Zapoznaj się ze środowiskiem wyrażania zgody i skonfiguruj fragmenty monitu o wyrażenie zgody aplikacji, aby użytkownicy końcowi i administratorzy mieli wystarczającą ilość informacji, aby określić, czy ufają Twojej aplikacji.

Zminimalizuj liczbę przypadków, w których użytkownik musi wprowadzić poświadczenia logowania podczas korzystania z aplikacji, próbując przeprowadzić uwierzytelnianie dyskretne (pozyskiwanie tokenu dyskretnego) przed przepływami interaktywnymi.

Nie używaj polecenia "prompt=consent" dla każdego logowania. Użyj polecenia prompt=consent, jeśli ustalisz, że musisz poprosić o zgodę na dodatkowe uprawnienia (na przykład jeśli zmieniono wymagane uprawnienia aplikacji).

Jeśli ma to zastosowanie, wzbogać aplikację o dane użytkownika. Korzystanie z interfejsu API programu Microsoft Graph jest łatwym sposobem na wykonanie tej czynności. Narzędzie Graph Explorer, które może pomóc w rozpoczęciu pracy.

Zarejestruj pełny zestaw uprawnień wymaganych przez aplikację, aby administratorzy mogli łatwo udzielić zgody dzierżawie. Użyj zgody przyrostowej w czasie wykonywania, aby ułatwić użytkownikom zrozumienie, dlaczego aplikacja żąda uprawnień, które mogą dotyczyć lub mylić użytkowników podczas pierwszego uruchamiania.

Zaimplementuj czyste środowisko wylogowania jednokrotnego. Jest to wymaganie dotyczące prywatności i zabezpieczeń oraz zapewnia dobre środowisko użytkownika.

Testowanie

Przetestuj zasady dostępu warunkowego, które mogą mieć wpływ na możliwość korzystania z aplikacji przez użytkowników.

Przetestuj aplikację przy użyciu wszystkich możliwych kont, które planujesz obsługiwać (na przykład konta służbowe, osobiste konta Microsoft, konta podrzędne i konta suwerenne).

Dodatkowe zasoby

Uzyskaj szczegółowe informacje na temat wersji 2.0:

• Platforma tożsamości Microsoft (omówienie)
• Dokumentacja protokołów Platforma tożsamości Microsoft
• Dokumentacja tokenów dostępu
• Dokumentacja tokenów identyfikatorów
• Dokumentacja bibliotek uwierzytelniania
• Uprawnienia i zgoda na platformie tożsamości firmy Microsoft
• Interfejs API programu Microsoft Graph