De meeste mensen denken dat identiteit gewoon een gebruikersnaam en wachtwoord is. Je voert ze in, krijgt toegang en klaar. Maar als bedrijf dat klanten bedient, wordt identiteit veel ingewikkelder. Wat als je app duizenden mensen moet laten registreren of laten inloggen met hun Google-account in plaats van nog een wachtwoord aan te maken? En hoe hou je al die klantgegevens veilig zonder ze te vermengen met je werknemerslijst? Dat is precies het probleem dat Microsoft Entra External ID moet oplossen. Dit is de situatie. Het vervangt Azure ADB2C volledig. Aan het eind van deze aflevering begrijp je wat External ID is, de drie manieren om het te gebruiken en waarom het belangrijk is voor klantgerichte apps. De oude manier, aparte identiteitssiloos. Stel je voor dat het 20 jaar geleden is en je een app voor klanten hebt gebouwd. Toen bouwde je zelf een inlogsysteem, schreef je code voor wachtwoorden, zette je een database op en maakte je zelf een wachtwoordvergeten procedure.

Dat werkte voor een kleine app met honderden gebruikers, maar naarmate apps groeiden, werd het snel ingewikkeld. Bedrijven wilden inloggen met Google of Facebook, multifactor authenticatie en miljoenenaccounts kunnen verwerken zonder dat alles vastliep. Dat allemaal zelf bouwen werd een nachtmerrie. Microsoft's eerste antwoord was Azure ADB2C. Het was een klantidentiteitsdienst die destijds een reëel probleem oploste. Maar hier begon de ellende. Het grootste probleem was custom policies en die regels waren geschreven in XML. Als je ooit met XML bestanden van honderden regels hebt gewerkt, weet je hoe pijnlijk dat is. Moeilijk te configureren, moeilijk te diebubben en als er iets misging, kon je veel succes wensen met het vinden van de oorzaak. Bovendien stond Azure ADB2C los van Microsoft's belangrijkste identiteitsplatform. Dus als je Microsoft 365 of Azure AD voor je medewerkers had, voelde B2C als een compleet nieuw product.

Zoals te verwachten viel, hadden IT-teams moeite met het onderhoud, vreesden ontwikkelaars ervoor en kregen klanten een stroeve ervaring waardoor ze afhaakten. Microsoft besefte dat er iets eenvoudigere en uniformers nodig was en dat werd Microsoft Entra External ID. Wat Microsoft Entra External ID eigenlijk is. Dus, wat is Microsoft Entra External ID nu precies? Hier is de simpelste definitie. Het is een cloud-identiteitsdienst voor externe gebruikers, klanten, partners en gasten, niet voor werknemers. Bekijk het zo. Stel je voor dat je bedrijf een kantoorpand heeft. Dat is je workforce tenant. Het is waar je werknemers werken, waar hun bureaus staan en waar hun badges hen toegang geven. Entra ID beheert dat gebouw. Stel je nu voor dat je een winkel opent voor klanten, een aparte ruimte met een eigen ingang, eigen regels en eigen beveiliging. Klanten dwalen niet door de kantine voor werknemers en werknemers krijgen niet per ongeluk toegang tot klantaccounts.

Dat is External ID. Het maakt deel uit van de Microsoft Entra familie, maar dan in een andere vorm. Het is gebouwd voor CIAM, Customer Identity & Access Management en het beheert de volledige levenscyclus van een externe gebruiker. Registreren, aanmelden, wachtwoordherstel, profielbeheer, MFA en tokenuitgifte. Het werkt met standaard protocollen zoals OAuth 2.0, OpenID Connect en SAML, zodat bijna elke app die about verbinding kan maken. Maar hier is het grote verschil met het oude Azure ADB2C. External ID is eenvoudiger. Geen aangepaste XML beleidsregels meer. In plaats daarvan configureer je gebruikersstromen direct in het beheerscentrum. Of je gebruikt aangepaste authenticatie extensies die aansluiten op je bestaande backend logica. Dezelfde kracht, minder gedoe. De drie kerngebruikscenario's. Dus, hoe gebruik je external ID eigenlijk? Er zijn drie hoofdscenario's. Ze dekken bijna elke situatie waarin je iemand moet beheren die geen werknemer is.

Begin met de meest voorkomende klantidentiteit ofwel B2C. Stel je voor dat je een app voor het bestellen van pizza's bouwt. Je wilt dat mensen zich registreren, bestellingen plaatsen en volgende week terugkomen. Je wilt dat ze zich aanmelden met hun Google-account in plaats van een nieuw wachtwoord aan te maken. En je moet hun naam, telefoonnummer en bezorgvoorkeuren verzamelen. External ID regelt dat allemaal. Je krijgt kant een klare registratie en aanmeldstromen. Je configureert welke kenmerken je wilt verzamelen, naam, telefoonnummer of wat je maar nodig hebt. Je stelt social login in met Google, Facebook of Apple. En wanneer een gebruiker zich verifieert, geeft external ID een token uit aan je app, zodat deze weet wie die persoon is. Dit is de vervanging voor Azure ADB2C en het is waar de meeste organisaties mee beginnen. Een ander scenario is business-to-business samenwerking, oftewel B2B.

Dit is wanneer je partners of leveranciers toegang moet geven tot je interne apps. Misschien heb je een SharePoint site die je externe logistieke partner moet zien of een project management tool die je freelance ontwerpers gebruiken. In dit scenario nodig je hen uit als gastgebruikers in je workforce tenant. External ID beheert de uitnodigingsmail, het proces waarbij ze de uitnodiging accepteren en het toegangsbeleid dat bepaalt wat ze kunnen zien. Dit bestaat eigenlijk al jaren als B2B-samenwerking binnen Azure AD. Maar nu valt het onder de paraplu van external ID, dus beheer je het op dezelfde plek als je klantidentiteiten. Dan is er nog machine-to-machine, ofwel M2M. Dit is minder zichtbaar voor eindgebruikers, maar net zo belangrijk. Soms moet je back-end service communiceren met een andere API, een betalingsverwerker, een data-analyse dienst of een interne microservice. Hier komt geen mens aan te pas, het is gewoon de ene applicatie die de andere aanroept.

External ID maakt gebruik van de OAuth 2.0 Client Credentials Flow. Je service verifieert zichzelf met een client-ID en een geheim, en ontvangt een token om de downstream API aan te roepen. Dit vereist de M2M Premium Add-on, dus er zijn kosten aan verbonden, maar voor het beveiligen van API naar API communicatie zit het ingebakken. Deze drie scenario's dekken vrijwel elke situatie rond externe identiteit die je tegenkomt. Maar er is een belangrijke beslissing die je moet nemen, en dat is waar die gebruikers daadwerkelijk verblijven. Want external ID kan op twee heel verschillende plekken draaien, een workforce tenant of een external tenant. Laten we de twee opties eens uiteenzetten. External ID kan draaien binnen je bestaande workforce tenant, of als een volledig gescheiden external tenant. Het is niet hetzelfde, en de verkeerde keuze maken kan later voor problemen zorgen. Laten we beginnen met de optie van de workforce tenant.

Je bedrijf heeft al een entra-ID tenant voor je medewerkers. Dat is je workforce tenant. Als je een functie genaamd Guest Self Service Sign Up inschakelt in die tenant, kunnen externe gebruikers zich aanmelden en belanden ze in dezelfde directory als je medewerkers. Hun accounts staan dan direct naast het account van je CEO. Voor eenvoudigere B2B scenario's, zoals het uitnodigen van een handjevol partners voor een SharePoint site, is het mengen in dezelfde directory prima. Het is eenvoudig in te stellen en je hoeft geen aparte tenant te beheren. Maar hier is het punt. Als je een app voor klanten bouwt met duizenden gebruikers, wil je niet dat die klanten in dezelfde directory staan als je medewerkers. Dat is een beveiligingsrisico. Een medewerker zou per ongeluk klantgegevens kunnen tegenkomen. Een configuratiewijziging bedoeld voor medewerkers kan de toegang van klanten beïnvloeden. En je branding voor inlogpagina's voor klanten zou gekoppeld zijn aan wat je hebt ingesteld voor je bedrijf.

Dat is niet ideaal. Het alternatief is de optie van de external tenant. Je creëert een gloednieuwe, geïsoleerde directory specifiek voor klantidentiteiten. Er zijn hier geen medewerkers aanwezig. Het is een volledig gescheiden ruimte. Herinner je je de vergelijking met het kantoorgebouw van eerder nog? De workforce tenant is je hoofdkantoor. De external tenant is de speciale winkel die je opent voor je klanten. Ze hebben hun eigen ingang, hun eigen regels en hun eigen beveiliging. Niets raakt vermengd. Dus, wat zijn de voordelen van een external tenant? Ten eerste krijg je een geïsoleerd gebruikersarchief. Klantgegevens blijven volledig gescheiden van werknemersgegevens, wat risico's vermindert en compliance vereenvoudigt. Ten tweede krijg je aparte branding. Je kunt de uitstraling van inlogpagina's specifiek aanpassen voor je klanten, zonder je bedrijfsomgeving te beïnvloeden. Ten derde krijg je de native authenticatie API voor mobiele apps, waarmee je volledig aangepaste inlogschermen bouwt in je iOS of Android app.

Geen browseromleidingen, geen loggen webweergave. En ten vierde krijg je mouw gebaseerde prijzen, oftewel maandelijks actieve gebruikers. Je betaalt alleen voor gebruikers die in een bepaalde maand daadwerkelijk inloggen, wat natuurlijk meegroeit met je klantenbestand. Dus, wanneer kies je wat? Dat is vrij eenvoudig. Als je een B2C-app bouwt met duizenden klanten, kies dan voor een externe tenant. Dat is de aanbevolen aanpak en waarvoor external idee is ontworpen. Als je alleen partners uitnodigt voor toegang tot interne bronnen, dan is de werkplek tenant prima. Het is cruciaal om het verschil te begrijpen voordat je begint met bouwen, want later migreren van de een naar de ander is niet eenvoudig. Beveiliging, MFA en voorwaardelijke toegang. Laten we het nu over beveiliging hebben. Als je klanten toegang geeft tot je app, moet je zorgen dat onbevoegden buiten blijven. External ID bevat dezelfde beveiligingsfuncties op bedrijfsniveau die Entra ID biedt voor werknemers.

Dat betekent multifactor authenticatie, voorwaardelijke toegang en risico gebaseerd beleid. Voor MFA heb je op dit moment twee opties. Een eenmalige toegangscode via e-mail is gratis. Het systeem stuurt een code naar de e-mail van de gebruiker. Zij voeren deze in en klaar. Een eenmalige toegangscode via SMS werkt op dezelfde manier, maar gaat naar hun telefoon en brengt providerkosten met zich mee. Let wel op, er is nog geen ondersteuning voor Microsoft Authenticator. Dat is een huidige beperking waar Microsoft waarschijnlijk aan werkt, maar voor nu is het e-mail of SMS. Voorwaardelijke toegang is waar het interessant wordt. Je kunt regels definiëren zoals verrijs MFA bij een gemiddeld of hoger inlogrisico, of blokkeert toegang uit landen waar we geen zaken doen. Het systeem evalueert elke inlogpoging in realtime. Als iemand probeert in te loggen vanaf een verdachte locatie of apparaat, kan het automatisch de beveiligingseisen opschroeven zonder dat je die logica zelf hoeft te bouwen.

Maar er is één functie die er echt uitspringt, step-up authenticatie. Dit is hoe het werkt. Stel dat een gebruiker inlogt op je app met alleen een wachtwoord om je productcatalogus te bekijken. Dat is prima voor activiteiten met een laag risico, maar als ze hun betalingsgeschiedenis willen inzien of een factuur willen downloaden, wil je aanvullende verificatie. Met step-up authenticatie kunt u MFA alleen vereisen voor specifieke onderdelen van uw app. De gebruiker krijgt pas een prompt wanneer deze toegang probeert te krijgen tot gevoelige informatie. En dit wordt achter de schermen volledig afgehandeld door external ideeën met behulp van authenticatiecontext. U bepaalt zelf welke delen van uw app extra beveiliging nodig hebben en het systeem regelt de rest. De gebruiker ervaart een soepele navigatie, terwijl de gevoelige gegevens goed beschermd blijven. Branding en gebruikerservaring Controle over de branding is een van de belangrijkste redenen waarom organisaties voor external idee kiezen in plaats van zelf een inlogsysteem te bouwen.

U krijgt volledige controle over de look en feel van uw aanmeld- en inlogpagina's, Upload uw logo, stijl achtergrondkleuren in, voeg een VV-con toe voor het browser-tabblad en pas de kop- en voetekst aan met links naar uw privacybeleid en servicevoorwaarden. Als u nog meer controle wilt, kunt u een aangepast CSS-bestand uploaden om lettertypes, knopkleuren en de layout te overschrijven. Het is uw merk, uw kleuren, u bepaalt alles. Nu wordt het een beetje ingewikkeld. Branding is globaal per tenant, niet per applicatie. Dus als u meerdere apps heeft, zoals een klantportal en een mobiele app, delen ze allemaal dezelfde gebrandmerkte pagina's. U kunt elke app niet een eigen uitstraling geven. Het oude Azure ADB2C stond wel branding per applicatie toe, maar external idee ondersteunt dat nog niet. Een andere beperking is dat foutmeldingen op inlogpagina's niet aanpasbaar zijn. Als iemand een e-mailadres invoert dat niet bestaat, krijgen ze iets te zien als, we konden geen account vinden met dit e-mailadres.

En u kunt die tekst niet wijzigen. Voor sommige organisaties is dat prima, maar voor anderen, vooral in gereguleerde sectoren of met een strikte merkstem, is het een echt probleem. Mobiele apps krijgen een betere optie. External ID heeft een native authenticatie API voor iOS en Android. In plaats van gebruikers door te sturen naar een inlogpagina in de browser, kunt u volledig aangepaste inlogschermen in uw app bouwen. Geen browseromleiding, geen onhandige webweergave. De gebruiker blijft de hele tijd in uw app en u heeft de controle over elke pixel. Het is een veel soepelere ervaring en een van de functies die Azure ADB2C nooit had. Migratie van Azure ADB2C Als u al Azure ADB2C gebruikt, vraagt u zich waarschijnlijk af wat dit voor u betekent. Het zit zo, Microsoft blijft B2C in ieder geval tot 2030 ondersteunen. Uw bestaande tenants stoppen dus niet morgen met werken, maar er komen geen nieuwe functies meer bij.

Alle innovatie, pas, keys, native authenticatie en fraudebescherming zijn exclusief voor external ID. U zit op een platform dat in feite bevroren is. Microsoft heeft officiële migratietools en richtlijnen gepubliceerd en er zijn twee paden afhankelijk van je schaal. Voor tenants met minder dan ongeveer 5 miljoen directory objecten, gebruikers, groepen en aangepaste kenmerken, is een standaard migratie relatief eenvoudig. Het werkt als een tenant-naar-tenant verplaatsing. Je maakt een nieuwe external ID tenant aan, migreert je gebruikers en hun inloggegevens en schakelt vervolgens je applicaties over. Microsoft biedt tools voor bulk export en import van gebruikers en je kunt just-in-time wachtwoord migratie gebruiken om verstoring tijdens de overgang te beperken. Voor grotere tenants met meer dan 5 miljoen directory objecten is er de high-scale compatibility mode, oftewel HSC. In deze modus draaien Azure ADB2C en External ID zij aan zij in dezelfde tenant.

Je bestaande B2C-eindpunten blijven actief terwijl je geleidelijk applicaties overzet. Het is ontworpen voor organisaties die niet miljoenen gebruikers van de ene op de andere dag kunnen migreren, maar er zijn compromissen. Geen sociale identiteitsproviders, geen paskeys, beperkte voorwaardelijke toegang en sommige functies zijn simpelweg niet beschikbaar. Zie het als een overbruggingstrategie, niet als een permanente oplossing. Nu, een grote verandering. Aangepast beleid is verdwenen. Als je complexe authenticatiestromen hebt gebouwd met het op XML gebaseerde Identity Experience Framework van Azure ADB2C, werken deze niet in External ID. Je zult die logica opnieuw moeten opbouwen met gebruikersstromen en aangepaste authenticatie-extensies. Er is geen magische tool die je XML conforteert naar het nieuwe formaat. Je zult het werk zelf moeten doen. Dus, waar komt het op neer? Als je vandaag vanaf nul begint, gebruik dan External ID.

Er is geen reden om überhaupt naar B2C te kijken. Als je een bestaande B2C-tenant hebt, begin dan nu met het plannen van je migratie. Je hebt tot 2030, maar wachten tot het laatste moment betekent dat je moet haasten door een complexe migratie terwijl je bestaande apps draaiende moet houden. Begin klein. Kies één applicatie, migreer deze, test het, leer van het proces en doe dan de rest. Ontwikkelaarservaring en automatisering. Microsoft heeft zich echt gericht op het makkelijk maken van External ID voor ontwikkelaars en het is een enorme verandering ten opzichte van het oude B2C-beleid. Ken je die XML-bestanden die honderden regels lang waren en kapot gingen als je één haakje verkeerd plaatste? Dat is verleden tijd. Er is een Visual Studio Code-extensie genaamd Microsoft Entra External ID. Nadat je bent aangemeld, kun je door je tenant bladeren, gebruikersstromen bekijken, ze downloaden als JSON-bestanden en zelfs je branding bekijken, zonder je editor te verlaten.

Je ziet hoe je aanmeldingspagina eruit ziet voordat je deze publiceert. Dan is er nog de Microsoft Graph API. Bijna elke External ID resource, zoals gebruikersstromen, app-registraties en branding, kan programmatisch worden beheerd. Dat betekent dat je de tenant-setup kunt automatiseren in je CI-CD pipelines met PowerShell of Rest aanroepen. Maak een nieuwe tenant aan, configureer de gebruikersstromen, registreer je app-en-style branding in, allemaal vanuit een script. Als je meerdere omgevingen beheert, bespaart dat enorm veel tijd. Aangepaste authenticatie-extensies vormen de echte kracht. In plaats van complexe XML, breed je authenticatiestromen uit met eenvoudige HTTP aanroepen naar Azure Functions. Er zijn vier gebeurtenissen waar je op kunt inhaken. Bij het starten van tokenuitgifte kun je aangepaste claims aan tokens toevoegen, zoals rollen- of loyaliteitsniveau informatie. Bij het verzamelen van attributen kun je aanmeldgegevens valideren of vooraf invullen door je eigen bekende aan te roepen.

En met e-mail OTP verzonden, kun je de verificatie e-mails aanpassen. Het biedt dezelfde flexibiliteit als B2C, maar in een model waar elke ontwikkelaar mee kan werken. Er zijn wel beperkingen waar je rekening mee moet houden. Er zijn nog geen Microsoft Graph meldingen, dus je kunt niet automatisch een workflow starten wanneer een nieuwe gebruiker zich aanmeldt. Sommige configuraties moeten nog handmatig in het centrum worden gedaan en er is geen ingebouwde pagina voor profielbewerking. Als je wilt dat gebruikers hun informatie bijwerken, moet je die pagina zelf in je app bouwen en de Graph API aanroepen. Maar de richting is duidelijk. Microsoft wil dat External ID volledig automatiseerbaar wordt. Dat maakt het gemakkelijker om op schaal te beheren. Dus nu weet je het Microsoft. Entra External ID is de moderne vervanger voor Azure ADB2C, verenigd onder het Entra-merk. De drie use cases, klantidentiteit, partnersamenwerking en machine-to-machine, dekken bijna elke externe identiteitsbehoefte die je zult tegenkomen.

De belangrijkste beslissing is of je je workforce-tenant gebruikt of een afzonderlijke externe tenant aanmaakt. Voor klantgerichte apps is een aparte tenant bijna altijd beter. Identiteit is de voordeur van je applicatie. Het goed, veilig, herkenbaar en eenvoudig inrichten heeft direct invloed op het gebruikersvertrouwen en de bedrijfsgroei. Jouw huiswerk? Ga naar entra.microsoft.com, maak een externe tenant aan en probeer de aan de slag, gids. Deze lijkt je in enkele minuten door het opzetten van een voorbeeld-app. Abonneer je voor meer uitleg in begrijpelijke taal over het identiteitsplatform van Microsoft.