Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op: 
Externe tenants (meer informatie)
Door de browser gedelegeerde verificatie en systeemeigen verificatie zijn twee aanmeldingsmethoden in Microsoft Entra Externe id die bepalen hoe uw klantgerichte app de verificatie-ervaring afhandelt. Beide benaderingen worden volledig ondersteund, maar ze verschillen in gebruikerservaring, ontwikkelingsinspanning en beveiligingsmodel. Als u deze verschillen begrijpt, kunt u de methode kiezen die het beste bij uw app past.
Met browser-gedelegeerde verificatie leidt uw app gebruikers om naar een Microsoft gehoste aanmeldingspagina in een systeembrowser of ingesloten webweergave. Microsoft Entra de volledige verificatiestroom afhandelt en uw app tokens ontvangt nadat de aanmelding is voltooid. Deze aanpak vereist minimale code en biedt ingebouwde huisstijlaanpassing.
Met natieve verificatie bouwt u de gebruikersinterface voor aanmelden rechtstreeks in uw app met behulp van de Microsoft Authentication Library (MSAL) SDK of de systeemeigen verificatie-API. Gebruikers verlaten uw app nooit. U bepaalt elk aspect van de gebruikersinterface, maar uw team is verantwoordelijk voor het bouwen en onderhouden van de verificatie-ervaring.
Wanneer gebruikt u door de browser gedelegeerde verificatie
Door de browser gedelegeerde verificatie is des te beter geschikt wanneer:
- Uw app kan een browseromleiding tijdens het inloggen ondersteunen zonder de gebruikerservaring te verstoren.
- U geeft de voorkeur aan lagere implementatie- en onderhoudswerkzaamheden. Microsoft beheert automatisch beveiligingsupdates en nieuwe functies.
- U wilt het breedste scala aan platforms en talen ondersteunen met minder code.
Zie de functievergelijking voor specifieke beschikbaarheid van functies.
Wanneer moet u systeemeigen verificatie gebruiken
Systeemeigen verificatie is de beste oplossing wanneer:
- U hebt volledige controle over de aanmeldingsgebruikersinterface nodig, zodat deze naadloos in uw app past.
- Een browseromleiding zou de gebruikerservaring voor uw doelplatform verstoren.
- Uw organisatie werkt zowel de app als de autorisatieserver en uw gebruikers zien ze als één entiteit.
- Uw ontwikkelteam kan rekening houden met de extra implementatie-inspanningen en doorlopend onderhoud.
Zie de functievergelijking voor specifieke beschikbaarheid van functies.
Vergelijking van functies
In de volgende tabel ziet u welke functies beschikbaar zijn in elke benadering.
| Feature | Door de browser gedelegeerde verificatie | Ingebouwde authenticatie |
|---|---|---|
| Registreren en aanmelden met eenmalige wachtwoordcode voor e-mail (OTP) | ✔️ | ✔️ |
| Registreren en aanmelden met e-mail en wachtwoord | ✔️ | ✔️ |
| Aanmelden met e-mailadres en wachtwoord kan gebruikersnaam (alias) en wachtwoord gebruiken | ✔️ | ✔️ |
| Zelfstandig wachtwoordherstel (SSPR) | ✔️ | ✔️ |
| Aangepaste claimsaanbieder | ✔️ | ✔️ |
| Meervoudige verificatie met een eenmalige wachtwoordcode (OTP) voor e-mail | ✔️ | ✔️ |
| Meervoudige verificatie met eenmalige sms-wachtwoordcode (OTP) | ✔️ | ✔️ |
| Aanmelden via sociale-id-provider (Apple, Facebook en Google)1 | ✔️ | ✔️ |
| Eenmalige aanmelding (SSO)2 | ✔️ | ✔️ |
1 Zelfs met systeemeigen verificatie wordt er voor sociale aanmelding nog steeds een browservenster gebruikt voor de identiteitsproviderstap.
2 Native authenticatie ondersteunt alleen Single Sign-On (SSO) voor ingesloten webweergaven. Single Sign-On (SSO) tussen apps via systeembrowsers is niet beschikbaar met native authenticatie.
Ondersteunde talen en frameworks
De volgende talen en frameworks worden ondersteund voor elke benadering.
| Approach | Ondersteunde talen en frameworks |
|---|---|
| Door de browser gedelegeerde verificatie |
|
| Ingebouwde authenticatie |
|
Beveiligingsoverwegingen
Door de browser gedelegeerde verificatie is de veiligere optie. Microsoft beheert het aanmeldingsoppervlak, waardoor de blootstelling van uw app aan phishing- en aanmeldingsaanvallen wordt verminderd.
Met systeemeigen verificatie deelt uw ontwikkelteam de beveiligingsverantwoordelijkheid met Microsoft Entra. Uw team moet de aanbevolen beveiligingsprocedures volgen voor het verwerken van gebruikersreferenties. Voordat u systeemeigen verificatie kiest, moet u de gevolgen voor de beveiliging bespreken met de bedrijfseigenaar en het ontwikkelingsteam van uw app.
Volgende stappen
Nadat u een aanpak hebt gekozen, registreert u uw app om uw integratie voort te zetten of gaat u terug naar de planningshandleiding voor de volledige reeks stappen:
Door de browser gedelegeerde verificatie:
Ingebouwde verificatie: