Systeemeigen verificatie (preview)
Van toepassing op:Externe tenants
van werknemers (meer informatie)
Met de systeemeigen verificatie van Microsoft Entra hebt u volledige controle over het ontwerp van de aanmeldingservaring van uw mobiele toepassing. In tegenstelling tot browseroplossingen kunt u met systeemeigen verificatie visueel aantrekkelijke, pixel-perfecte verificatieschermen maken die naadloos in de interface van uw app passen. Met deze aanpak kunt u de gebruikersinterface volledig aanpassen, inclusief ontwerpelementen, logoplaatsing en lay-out, waardoor een consistent en merkachtig uiterlijk wordt gegarandeerd.
Het aanmeldingsproces van de standaard mobiele app, dat afhankelijk is van door de browser gedelegeerde verificatie, leidt vaak tot een verstorende overgang tijdens de verificatie. Gebruikers worden tijdelijk omgeleid naar een systeembrowser voor verificatie, zodat ze alleen weer naar de app worden gebracht zodra de aanmelding is voltooid.
Hoewel door de browser gedelegeerde verificatie voordelen biedt, zoals verminderde aanvalsvectoren en ondersteuning voor eenmalige aanmelding (SSO), biedt het beperkte aanpassingsopties voor gebruikersinterfaces en een slechte gebruikerservaring.
Beschikbare verificatiemethoden
Op dit moment ondersteunt systeemeigen verificatie de id-provider van lokale accounts voor twee verificatiemethoden:
- E-mail met eenmalige wachtwoordcode (OTP)-aanmelding.
- Aanmelding via e-mail en wachtwoord met ondersteuning voor selfservice voor wachtwoordherstel (SSPR).
Systeemeigen verificatie biedt nog geen ondersteuning voor federatieve id-providers, zoals sociale of zakelijke identiteiten.
Wanneer moet u systeemeigen verificatie gebruiken
Als het gaat om het implementeren van verificatie voor mobiele apps op externe id, hebt u twee opties:
- Door Microsoft gehoste, door de browser gedelegeerde verificatie.
- Volledig aangepaste op SDK gebaseerde systeemeigen verificatie.
De methode die u kiest, is afhankelijk van de specifieke vereisten van uw app. Hoewel elke app unieke verificatiebehoeften heeft, zijn er enkele algemene overwegingen waarmee u rekening moet houden. Of u nu systeemeigen verificatie of door een browser gedelegeerde verificatie kiest, Microsoft Entra Externe ID beide ondersteunt.
In de volgende tabel worden de twee verificatiemethoden vergeleken, zodat u de juiste optie voor uw app kunt kiezen.
Door de browser gedelegeerde verificatie | Systeemeigen verificatie | |
---|---|---|
Gebruikersverificatie-ervaring | Gebruikers worden naar een systeembrowser of ingesloten browser geleid om verificatie alleen terug te sturen naar de app wanneer de aanmelding is voltooid. Deze methode wordt aanbevolen als de omleiding geen negatieve invloed heeft op de ervaring van de eindgebruiker. | Gebruikers hebben een uitgebreide, systeemeigen mobiele-eerste registratie en aanmeldingstraject zonder de app te verlaten. |
Aanpassingservaring | Beheerde huisstijl- en aanpassingsopties zijn beschikbaar als een out-of-the-box-functie. | Deze API-gerichte benadering biedt een hoog aanpassingsniveau en biedt uitgebreide flexibiliteit bij het ontwerpen en de mogelijkheid om op maat gemaakte interacties en stromen te maken. |
Toepasselijkheid | Geschikt voor werknemers, B2B- en B2C-apps, kan het worden gebruikt voor systeemeigen apps, toepassingen met één pagina en web-apps. | Voor mobiele apps van de klant, wanneer dezelfde entiteit de autorisatieserver en de app gebruikt en de gebruiker ze beide als dezelfde entiteit beschouwt. |
Live werk gaan | Laag. Gebruik het direct uit de doos. | Hoog. De ontwikkelaar bouwt, eigenaar is en onderhoudt de verificatie-ervaring. |
Onderhoudsinspanning | Laag. | Hoog. Voor elke functie die Door Microsoft wordt uitgebracht, moet u de SDK bijwerken om deze te gebruiken. |
Beveiliging | Meest veilige optie. | Beveiligingsverantwoordelijkheid wordt gedeeld met ontwikkelaars en best practices moeten worden gevolgd. Het is gevoelig voor phishingaanvallen. |
Ondersteunde talen en frameworks |
|
|
Beschikbaarheid van functies
In de volgende tabel ziet u de beschikbaarheid van functies voor door de browser gedelegeerde en systeemeigen verificatie.
Door de browser gedelegeerde verificatie | Systeemeigen verificatie | |
---|---|---|
Eenmalige wachtwoordcode (OTP) registreren en aanmelden met e-mail | ✔️ | ✔️ |
Registreren en aanmelden met e-mail en wachtwoord | ✔️ | ✔️ |
Selfservice voor wachtwoordherstel (SSPR) | ✔️ | ✔️ |
Aanmelding van sociale id-provider | ✔️ | ❌ |
Meervoudige verificatie met eenmalige wachtwoordcode voor e-mail (OTP) | ✔️ | ❌ |
Eenmalige aanmelding (SSO) | ✔️ | ❌ |
Systeemeigen verificatie gebruiken
U kunt apps bouwen die systeemeigen verificatie gebruiken met behulp van onze systeemeigen verificatie-API's of de MSAL-SDK (Microsoft Authentication Library) voor Android en iOS. Waar mogelijk raden we u aan MSAL te gebruiken om systeemeigen verificatie toe te voegen aan uw apps.
Zie de volgende tabel voor meer informatie over systeemeigen verificatievoorbeelden en zelfstudies.
Language/ Platform |
Handleiding voor codevoorbeelden | Handleiding voor bouwen en integreren |
---|---|---|
Android (Kotlin) | • Gebruikers aanmelden | • Gebruikers aanmelden |
iOS (Swift) | • Gebruikers aanmelden | • Gebruikers aanmelden |
Als u van plan bent om een mobiele app te maken in een framework dat momenteel niet wordt ondersteund door MSAL, kunt u onze verificatie-API gebruiken. Volg dit naslagartikel over api's voor meer informatie.
Gerelateerde inhoud
- Zelfstudies voor systeemeigen Android-verificatie.
- Zelfstudies voor systeemeigen iOS-verificatie.
- Documentatie voor systeemeigen verificatie-API.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort: Gedurende 2024 worden GitHub Issues uitgefaseerd als het feedbackmechanisme voor inhoud. Dit wordt vervangen door een nieuw feedbacksysteem. Ga voor meer informatie naar:Feedback verzenden en bekijken voor