Uwierzytelnianie natywne (wersja zapoznawcza)
Dotyczy:
Dzierżawcy siły roboczej — dzierżawcy zewnętrzni 
(dowiedz się więcej)
Natywne uwierzytelnianie firmy Microsoft Entra umożliwia pełną kontrolę nad projektowaniem środowisk logowania do aplikacji mobilnych. W przeciwieństwie do rozwiązań opartych na przeglądarce, uwierzytelnianie natywne umożliwia tworzenie atrakcyjnych wizualnie ekranów uwierzytelniania, które bezproblemowo łączą się z interfejsem aplikacji. Dzięki temu podejściu można w pełni dostosować interfejs użytkownika, w tym elementy projektowe, umieszczanie logo i układ, zapewniając spójny i markowy wygląd.
Standardowy proces logowania aplikacji mobilnej, który opiera się na uwierzytelnianiu delegowanym przez przeglądarkę, często powoduje destrukcyjne przejście podczas uwierzytelniania. Użytkownicy są tymczasowo przekierowywani do przeglądarki systemowej na potrzeby uwierzytelniania, tylko po zakończeniu logowania do aplikacji.
Chociaż uwierzytelnianie delegowane przez przeglądarkę oferuje korzyści, takie jak wektory mniejszego ataku i obsługa logowania jednokrotnego, oferuje ograniczone opcje dostosowywania interfejsu użytkownika i słabe środowisko użytkownika.
Dostępne metody uwierzytelniania
Obecnie uwierzytelnianie natywne obsługuje lokalnego dostawcę tożsamości konta dla dwóch metod uwierzytelniania:
- Wiadomość e-mail z logowaniem za pomocą jednorazowego kodu dostępu (OTP).
- Logowanie za pomocą poczty e-mail i hasła z obsługą samoobsługowego resetowania hasła (SSPR).
Uwierzytelnianie natywne nie obsługuje jeszcze federacyjnych dostawców tożsamości, takich jak tożsamości społecznościowe lub tożsamości przedsiębiorstwa.
Kiedy należy używać uwierzytelniania natywnego
Jeśli chodzi o implementację uwierzytelniania dla aplikacji mobilnych na identyfikatorze zewnętrznym, dostępne są dwie opcje:
- Uwierzytelnianie delegowane przez przeglądarkę hostowane przez firmę Microsoft.
- W pełni niestandardowe uwierzytelnianie natywne oparte na zestawie SDK.
Wybrane podejście zależy od konkretnych wymagań aplikacji. Chociaż każda aplikacja ma unikatowe potrzeby uwierzytelniania, należy pamiętać o kilku typowych zagadnieniach. Niezależnie od tego, czy wybierasz uwierzytelnianie natywne, czy uwierzytelnianie delegowane przez przeglądarkę, Tożsamość zewnętrzna Microsoft Entra obsługuje oba te elementy.
W poniższej tabeli porównaliśmy dwie metody uwierzytelniania, które pomogą Ci zdecydować, czy wybrać odpowiednią opcję dla aplikacji.
| Uwierzytelnianie delegowane przez przeglądarkę | Uwierzytelnianie natywne | |
|---|---|---|
| Środowisko uwierzytelniania użytkownika | Użytkownicy są przekierowywani do przeglądarki systemowej lub przeglądarki osadzonej, aby uwierzytelnianie było przekierowywane z powrotem do aplikacji po zakończeniu logowania. Ta metoda jest zalecana, jeśli przekierowanie nie ma negatywnego wpływu na środowisko użytkownika końcowego. | Użytkownicy mają bogatą, natywną podróż do rejestracji i logowania na urządzeniach przenośnych bez opuszczania aplikacji. |
| Środowisko dostosowywania | Opcje znakowania zarządzanego i dostosowywania są dostępne jako wbudowana funkcja. | To podejście skoncentrowane na interfejsie API oferuje wysoki poziom dostosowywania, zapewniając dużą elastyczność projektowania i możliwość tworzenia dostosowanych interakcji i przepływów. |
| Stosowanie | Odpowiednie dla pracowników, aplikacji B2B i B2C można jej używać w aplikacjach natywnych, aplikacjach jednostronicowych i aplikacjach internetowych. | W przypadku aplikacji mobilnych pierwszej firmy klienta, gdy ta sama jednostka obsługuje serwer autoryzacji i aplikację, a użytkownik postrzega je zarówno jako tę samą jednostkę. |
| Przejdź na żywo | Niski. Użyj go prosto z pudełka. | Wysoka. Deweloper tworzy, jest właścicielem i utrzymuje środowisko uwierzytelniania. |
| Nakład pracy konserwacyjnych | Niski. | Wysoka. Dla każdej funkcji, którą firma Microsoft wyda, należy zaktualizować zestaw SDK, aby go używał. |
| Bezpieczeństwo | Najbezpieczniejsza opcja. | Odpowiedzialność za zabezpieczenia jest współdzielona z deweloperami i należy przestrzegać najlepszych rozwiązań. Podatne na ataki wyłudzane informacje. |
| Obsługiwane języki i struktury |
|
|
Dostępność funkcji
W poniższej tabeli przedstawiono dostępność funkcji delegowanych w przeglądarce i uwierzytelniania natywnego.
| Uwierzytelnianie delegowane przez przeglądarkę | Uwierzytelnianie natywne | |
|---|---|---|
| Rejestrowanie się i logowanie przy użyciu jednorazowego kodu dostępu poczty e-mail (OTP) | ✔️ | ✔️ |
| Rejestrowanie się i logowanie przy użyciu poczty e-mail i hasła | ✔️ | ✔️ |
| Samoobsługowe resetowanie hasła (SSPR) | ✔️ | ✔️ |
| Logowanie dostawcy tożsamości społecznościowych | ✔️ | ❌ |
| Uwierzytelnianie wieloskładnikowe z jednorazowym kodem dostępu poczty e-mail (OTP) | ✔️ | ❌ |
| Logowanie jednokrotne | ✔️ | ❌ |
Jak używać uwierzytelniania natywnego
Aplikacje korzystające z uwierzytelniania natywnego można tworzyć przy użyciu naszych natywnych interfejsów API uwierzytelniania lub zestawu SDK biblioteki Microsoft Authentication Library (MSAL) dla systemów Android i iOS. Jeśli to możliwe, zalecamy dodanie uwierzytelniania natywnego do aplikacji przy użyciu biblioteki MSAL.
Aby uzyskać więcej informacji na temat przykładów i samouczków dotyczących uwierzytelniania natywnego, zobacz poniższą tabelę.
| Język/ Platforma |
Przykładowy przewodnik po kodzie | Przewodnik dotyczący kompilowania i integrowania |
|---|---|---|
| Android (Kotlin) | • Logowanie użytkowników | • Logowanie użytkowników |
| iOS (Swift) | • Logowanie użytkowników | • Logowanie użytkowników |
Jeśli planujesz utworzyć aplikację mobilną w strukturze, która nie jest obecnie obsługiwana przez bibliotekę MSAL, możesz użyć naszego interfejsu API uwierzytelniania. Aby uzyskać więcej informacji, postępuj zgodnie z tym artykułem dokumentacji interfejsu API.
Powiązana zawartość
- Samouczki dotyczące uwierzytelniania natywnego systemu Android.
- Samouczki dotyczące uwierzytelniania natywnego dla systemu iOS.
- Dokumentacja interfejsu API uwierzytelniania natywnego.