Die meisten Menschen denken bei Identität eigentlich nur an Benutzernamen und Passwort. Man gibt beides ein, erhält Zugriff und fertig. Doch für ein Unternehmen, das Kunden betreut, ist Identität weitaus komplexer. Was ist, wenn sich tausende von Personen in ihrer App anmelden oder ihr Google-Konto nutzen wollen, statt ein weiteres Passwort zu erstellen? Und wie halten sie all diese Kundendaten sicher, ohne sie mit ihrem Mitarbeiterverzeichnis zu vermischen? Genau dieses Problem soll Microsoft Entra External ID lösen. Bester Punkt. Es ersetzt Azure ID B2C vollständig? Am Ende dieser Folge werden Sie verstehen, was External ID ist, die drei wichtigsten Einsatzbereiche kennen und wissen, warum es für kundenorientierte Apps wichtig ist. Der alte Weg? Getrennte Identitätssilos. Stellen Sie sich vor, es ist 20 Jahre her und Sie haben eine App für Kunden entwickelt. Damals hat man ein eigenes Login-System entwickelt, den Code für Passwörter geschrieben, eine Datenbank zur Speicherung eingerichtet und den Passwort vergessen Ablauf von Grund auf neu erstellt.

Für eine kleine App mit wenigen hundert Nutzern funktionierte das gut, doch mit zunehmendem Wachstum wurde es schnell kompliziert. Unternehmen mussten Nutzern ermöglichen, sich über Google oder Facebook anzumelden, benötigten Multifaktor-Authentifizierung und mussten Millionen von Konten stabil verwalten. Das alles selbst zu bauen, wurde zu einem Albtraum. Microsofts erste Antwort darauf Azure AD B2C. Es war ein Identitätsdienst für Kunden, der damals ein echtes Problem löste. Doch hier begannen die Schwierigkeiten. Das größte Problem waren die sogenannten benutzerdefinierten Richtlinien, die in XML geschrieben wurden. Wer schon einmal mit hunderten Zeilen langen XML-Dateien gearbeitet hat, weiß genau, wie mühsam das ist. Schwer zu konfigurieren, schwer zu debuggen und wenn etwas kaputt ging, viel Erfolg bei der Fehlersuche, bei der Fehlersuche. Zudem war Azure AD B2C von Microsofts Hauptidentitätsplattform getrennt.

Wenn sie also bereits Microsoft 365 oder Azure AD für ihre Mitarbeiter nutzten, fühlte sich B2C an wie ein komplett neues Produkt, das man erlernen musste. Wie zu erwarten war, hatten IT-Teams Probleme bei der Wartung, Entwickler scheuten die Arbeit damit und Kunden bekamen eine umständliche Anmeldung, die sie zum Abspringen bewegte. D. Microsoft erkannte, dass eine einfachere und einheitlichere Lösung nötig war und genau das wurde Microsoft Entra External ID. Was Microsoft Entra External ID eigentlich ist? Was genau ist also Microsoft Entra External ID? Ist die einfachste Definition. Es ist ein Cloud-Identitätsdienst für externe Benutzer, Kunden, Partner und Gäste, nicht für Mitarbeiter. Stellen Sie sich so vor. Stellen Sie sich vor, Ihr Unternehmen besitzt ein Bürogebäude. Das ist Ihr Workforce Tenant. Hier arbeiten Ihre Mitarbeiter, hier befinden Sie Ihre Schreibtische und hier halten Sie mit Ihren Ausweisen zu.

Entra ID verwaltet dieses Gebäude. Stellen Sie sich nun vor, Sie eröffnen eine Verkaufsfläche für Kunden, einen separaten Bereich mit eigenem Eingang, eigenen Regeln und Regeln und eigener Sicherheit. Kunden verlaufen sich nicht im Pausenraum der Mitarbeiter und Mitarbeiter greifen nicht versehentlich auf Kundenkonten zu. Das ist External ID. Es ist Teil der Microsoft Entra-Familie, aber eine andere Variante. Es wurde für CRM, Customer Identity and Access Management, entwickelt und verwaltet den gesamten Lebenszyklus eines externen Benutzers. Registrierung, Anmeldung, Passwortzurücksetzung, Profilverwaltung, MFA und Tokenausstellung. Es arbeitet mit Standardprotokollen wie OAuth 2.0, OpenID Connect und SAML, sodass fast jede App, die Sie entwickeln, eine Verbindung herstellen kann. Aber hier ist der große Unterschied zum alten Azure AD B2C. External ID ist einfach. Keine Benutzer definiert Nix-A-Mail-Richtlinie mehr.

Stattdessen konfigurieren Sie Benutzerabläufe direkt im Admin-Center. Oder Sie nutzen benutzerdefinierte Authentifizierungserweiterungen, die an Ihre bestehende Backend-Logik anknüpfen. Gleiche Leistung, weniger Kopf zerbrechen. Die drei Kernanwendungsfälle. Wie verwendet man also External ID in der Praxis? Es gibt drei Hauptszenarien. Sie decken fast jede Situation ab, in der Sie jemanden verwalten müssen, der kein Mitarbeiter ist. Beginnen wir mit dem häufigsten Fall, Kundenidentität oder B2C. Stellen Sie sich vor, Sie entwickeln eine App für Pizza-Bestellungen. Sie benötigen Leute, die sich registrieren, Bestellungen aufgeben und nächste Woche wiederkommen. Sie möchten, dass Sie sich mit Ihrem Google-Konto anmelden, anstatt ein weiteres Passwort zu erstellen. Und Sie müssen Namen, Telefonnummer und Lieferpräferenzen erfassen, erfassen. External ID erledigt all das. Sie erhalten vorgefertigte Registrierungs- und Anmeldeabläufe.

Sie konfigurieren, welche Attribute erfasst werden sollen. Name, Telefonnummer oder was auch immer Sie benötigen. Sie richten eine soziale Anmeldung über Google, Facebook oder Apple ein. Und wenn sich ein Benutzer authentifiziert, stellt External ID ein Token für Ihre App aus, damit diese weiß, wer die Person ist. Dies ist der Ersatz für Azure AD B2C und der Punkt, an dem die meisten Unternehmen beginnen. Ein weiteres Szenario ist die Zusammenarbeit zwischen Unternehmen, also B2B. Dies ist der Fall, wenn Sie Partnern oder Anbietern Zugriff auf Ihre internen Apps gewähren müssen. Vielleicht haben Sie eine SharePoint-Seite, die Ihr externer Logistikpartner sehen muss, oder ein Projektmanagement-Tool für Ihre freiberuflichen Designer. In diesem Szenario laden Sie sie als Gastbenutzer in Ihren Mitarbeitermandanten ein. External ID verwaltet die Einladungs-E-Mail, den Einlösungsprozess, bei dem Sie die Einladung annehmen, und die Zugriffsrichtlinien, die steuern, was Sie sehen können.

Dies gibt es tatsächlich schon seit Jahren als B2B-Zusammenarbeit innerhalb von Azure AD Hedi. Aber jetzt gehört es zum External ID-Angebot, sodass Sie es zentral wie Ihre Kundenidentitäten verwalten. Dann gibt es noch Machine-to-Machine oder M2M. Dies ist für Endbenutzer weniger sichtbar, aber genauso wichtig. Manchmal muss Ihr Backend-Dienst mit einer anderen API, einem Zahlungsdienstleister, einem Analyse-Dienst oder einem internen Microservice kommunizieren. Dabei ist kein Mensch involviert, es ist lediglich eine Anwendung, die eine andere auch. External ID verwendet hierfür den OAuth 2.2 Client Credentials Flow. Ihr Dienst authentifiziert sich über eine Client-ID und ein Secret und erhält ein Token für den API-Aufruf. Dies erfordert das M2M Premium-Add-On, was mit Kosten verbunden ist, aber die API zu API-Sicherung ist direkt integriert. Diese drei Szenarien decken fast jede Situation mit externen Identitäten ab, der Sie begegnen werden.

Es gibt jedoch eine wichtige Entscheidung, die Sie treffen müssen. Wo sollen diese Benutzer eigentlich verwaltet werden? Denn External ID kann an zwei sehr unterschiedlichen Orten betrieben werden, im Workforce oder im externen Mandanten. Lassen Sie uns die beiden aufschlüssel. External ID kann in Ihrem bestehenden Workforce-Mandanten laufen oder als völlig separater externer Mandant. Das ist nicht dasselbe und die falsche Wahl kann später zu Problemen führen. Beginnen wir mit der Workforce-Mandanten-Option. Ihr Unternehmen verfügt bereits über einen Entra-ID-Mandanten für Ihre Mitarbeiter. Das ist Ihr Workforce-Mandant. Wenn Sie die Funktion für die Self-Service-Registrierung von Gästen aktivieren, können sich externe Benutzer registrieren und landen im selben Verzeichnis wie Ihre Mitarbeiter. Deren Konten liegen dann direkt neben denen Ihres CEOs. Für einfachere B2B-Szenarien, etwa das Einladen weniger Partner auf eine SharePoint-Seite, ist das Mischen im selben Verzeichnis völlig in Ordnung.

Es ist einfach einzurechten und Sie müssen keinen separaten Mandanten verwalten. Aber es gibt eine Haken. Wenn Sie eine kundenorientierte App mit tausenden Benutzern entwickeln, möchten Sie nicht, dass diese Kunden im selben Verzeichnis wie Ihre Mitarbeiter geführt werden. Das stellt ein Sicherheitsrisiko dar. Ein Mitarbeiter könnte versehentlich auf Kundendaten zugreifen. Eine Konfigurationsänderung für Mitarbeiter könnte den Kundenzugriff beeinträchtigen. Und das Branding für Ihre Kundenanmeldeseiten wäre an das Branding Ihres Unternehmens gebunden. Das ist nicht ideal. Die Alternative ist die Option eines externen Mandants. Sie erstellen ein völlig neues isoliertes Verzeichnis speziell für Kundenidentitäten. Hier sind keine Mitarbeiterinnen. Es ist in vollständig getrennte Bereichen. Erinnern Sie sichern das Bürogebäudebeispiel von vorhin. Der Workforce-Mandant ist Ihre Unternehmenszentrale.

Der externe Mandant ist das separate Ladengeschäft, das Sie für Ihre Kunden eröffnen. Sie haben einen eigenen Eingang, eigene Regeln und eine eigene Sicherheit. Nichts wird miteinander vermischt. Was sind also die Vorteile eines externen Mandanten? Erstens einen isolierten Benutzerspeicher. Kundendaten bleiben vollständig von Mitarbeiterdaten getrennt, was Risiken mindert und die Compliance vereinfacht. Zweitens erhalten Sie ein separatisches Branding. Sie können das Aussehen der Anmeldeseiten speziell für Ihre Kunden anpassen, ohne Ihren Unternehmenszentren zu beeinflussen. Drittens erhalten Sie die native Authentifizierungs-API für mobile Apps, mit der Sie völlig individuelle Anmeldebildschirme in Ihrer iOS- oder Android-App erstellen können. Keine Browser-Weiterleitung, keine schwerfälligen Webansichten. Und viertens erhalten Sie eine MAU-basierte Preisgestaltung, also monatlich aktive Benutzer.

Sie zahlen nur für Benutzer, die sich tatsächlich in einem bestimmten Monat anmelden, was mit Ihrem Kundenwachstum skaliert. Wann wählen Sie also was? Das ist ziemlich unkompliziert. Wenn Sie eine B2C-App mit tausend von Kunden entwickeln, nutzen Sie einen externen Tenant. Das ist der empfohlene Ansatz. Und genau dafür wurde externe RD entwickelt. Wenn Sie nur Partner einladen, auf interne Ressourcen zuzugreifen, ist die Workforce-Tenant-Option in Ordnung. Der Schlüssel liegt darin, den Unterschied vor dem Entwicklungsbeginn zu verstehen, da eine spätere Migration nicht trivial ist. Sicherheit MFA und bedingter Zugriff Lassen Sie uns nun über Sicherheit sprechen. Wenn Sie Kunden Ihre App lassen, müssen Sie sicherstellen, dass die falschen Personen draußen bleiben. External ID bietet dieselben Sicherheitsfunktionen der Enterprise-Klasse wie EntraID für Mitarbeiter. Das bedeutet Multifaktor-Authentifizierung, bedingter Zugriff und risikobasierte Richtlinien.

Für MFA haben Sie derzeit zwei Optionen. Einmal Passwörter per E-Mail sind kostenlos. Das System sendet ein Code an die E-Mail des Benutzers, dieser gibt ihn einfertig. SMS einmal Passwörter funktionieren genauso, gehen aber an das Telefon, wobei Mobilfunkgebühren anfallen. Ein wichtiger Hinweis, es gibt noch keine Unterstützung für Microsoft Authenticator. Das ist eine aktuelle Einschränkung, an der Microsoft wahrscheinlich arbeitet, aber momentan sind es E-Mail oder SMS. Beim bedingten Zugriff wird es interessant. Sie können Regeln definieren, wie zum Beispiel die MFA erforderlich bei mittlerem oder höherem Anmelderrisiko oder Zugriff aus Ländern blockieren, in denen wir nicht geschäftlich tätig sind. Das System bewertet jeden Anmeldeversuch in Echtzeit. Wenn jemand versucht, sich von einem Standort oder Gerät aus anzumelden, das verdächtig erscheint, können die Sicherheitsanforderungen automatisch erhöht werden, ohne dass Sie diese Logik selbst implementieren müssen.

Es gibt jedoch eine Funktion, die besonders hervorsticht, die Step-Up-Authentifizierung. So funktioniert es? Stellen Sie sich vor, ein Benutzer meldet sich nur mit einem Passwort an, um Ihren Produktkatalog zu durchsuchen. Das ist für Aktivitäten mit geringem Risiko in Ordnung. Aber wenn er seinen Zahlungsverlauf einsehen oder eine Rechnung herunterladen möchte, benötigen Sie eine zusätzliche Verifizierung. Mit Step-Up-Authentifizierung können Sie MFA nur für bestimmte Bereiche Ihrer App anfordern. Der Benutzer wird erst dann dazu aufgefordert, wenn er auf sensible Bereiche zugreifen. Dies wird von External-ID im Hintergrund über den sogenannten Authentifizierungskontext abgewickelt. Sie legen fest, welche Teile Ihrer App zusätzliche Sicherheit benötigen und das System erledigt den Rest. Der Benutzer genießt ein reibungsloses Erlebnis beim Browsen, während sensible Daten geschützt bleiben.

Branding und Benutzererfahrung Die Kontrolle über das Branding ist einer der Hauptgründe, warum sich Unternehmen für External-ID statt für ein eigenes Login-System entscheiden. Sie haben die volle Kontrolle über das Erscheinungsbild Ihrer Anmelde- und Registrierungsseiten, können Ihr Logo hochladen, Hintergrundfarben festlegen, ein Favicon für den Browser-Tab hinzufügen, sowie Kopf- und Fußzeilen mit Links- zu Datenschutzbestimmungen und Nutzungsbedingungen anpassen. Für noch mehr Kontrolle können Sie eine benutzerdefinierte CSS-Datei hochladen, Schaltflächenfarben und das Layout zu überschreiben. Es ist Ihre Marke, Ihre Farben, Sie entscheiden über alles. Hier wird es nun etwas kompliziert. Das Branding ist global pro Tenant festgelegt, nicht pro Anwendung. Wenn Sie also mehrere Apps haben, etwa ein Kundenportal und eine mobile App, teilen sich alle dieselben gebrandeten Seiten. Sie können nicht jeder App ein eigenes Design geben.

Das alte Azure-ID-B2C ermöglichte ein Branding pro Anwendung, aber External-ID unterstützt dies derzeit noch nicht. Eine weitere Einschränkung, Fehlermeldungen auf Login-Seiten sind nicht anpassbar. Gibt jemand eine E-Mail-Adresse ein, die nicht existiert, erscheint eine Meldung wie Wir konnten kein Konto mit dieser E-Mail-Adresse finden. Und diesen Text können Sie nicht ändern. Für manche Unternehmen ist das in Ordnung, für andere, insbesondere in regulierten Branchen oder mit strikter Markenkommunikation, stellt dies ein echtes Problem dar. Für mobile Apps gibt es eine bessere Option. External-ID bietet eine native Authentifizierungs-API für iOS und Android. Anstatt Benutzer auf eine browserbasierte Login-Seite umzuleiten, können Sie vollständig eigene Login-Bildschirme direkt in Ihrer App erstellen, direkt in Ihrer App. Keine Browser-Weiterleitung, keine unhandlichen Webansichten. Der Benutzer bleibt die ganze Zeit in Ihrer App und Sie haben die Kontrolle über jedes Pixel.

Es ist ein wesentlich flüssigeres Erlebnis und eines jener Features, die Azure AD B2C nie hatte. Migration von Azure AD B2C. Wenn Sie bereits Azure AD B2C nutzen, fragen Sie sich wahrscheinlich, was das für Sie bedeutet. Die Sache ist die, Microsoft wird B2C mindestens bis 2030 weiter unterstützen. Ihre bestehenden Tendents funktionieren also auch morgen noch, aber es werden keine neuen Funktionen mehr hinzugefügt. Sämtliche Innovationen, Passkeys, native Authentifizierung, Betrugsschutz sind exklusiv für External-ID verfügbar. Sie befinden sich auf einer Plattform, die im Grunde genommen eingeführt wird. Microsoft hat offizielle Migrationswerkzeuge und Anleitungen veröffentlicht und es gibt je nach Umfang zwei verschiedene Wege. Für Tenants mit weniger als etwa 5 Millionen Verzeichnisobjekten, Benutzern, Gruppen und benutzerdefinierten Attributen ist die Standard-Migration relativ unkompliziert.

Es funktioniert wie ein Umzug von Tenant zu Tenant. Sie erstellen einen neuen External-ID-Tenant, migrieren Ihre Benutzer und deren Anmeldeinformationen und stellen dann Ihre Anwendungen um. Microsoft stellt Tools für den Massenexport und Import von Benutzern bereit und Sie können die Just-in-Time-Passwort-Migration nutzen, um Unterbrechungen während des Übergangs gering zu halten. Für größere Tenants mit über 5 Millionen Verzeichnisobjekten gibt es den High-Scale-Compatibility-Mode, kurz HSC. In diesem Modus laufen Azure AD B2C und External-ID parallel im selben Tenant. Ihre bestehenden B2C-N-Punkte bleiben aktiv, während Sie die Anwendungen nach und nach umstellen. Ist für Organisationen konzipiert, die nicht Millionen von Benutzern über Nacht migrieren können, bringt aber Kompromisse mit sich. Keine sozialen Identitätsanbieter, keine Passkeys, eingeschränkter bedingter Zugriff und einige Funktionen sind schlicht nicht verfügbar.

Betrachten Sie es als Überbrückungsstrategie, nicht als dauerhafte Lösung. Nun zu einer bedeutenden Änderung. Benutzerdefinierte geht es nicht mehr. Wenn Sie komplexe Authentifizierungsabläufe mit dem XML-basierten Identity Experience Framework von Azure AD B2C erstellt haben, funktionieren diese in External-ID nicht. Sie müssen diese Logik mithilfe von Benutzerabläufen und benutzerdefinierten Authentifizierungserweiterungen neu erstellen. Es gibt kein sauber Werkzeug, das XML in das neue Format konvertiert. Sie müssen die Arbeit einfach selbst erledigen. Hier ist also das Fazit. Wenn Sie heute neu anfangen, nutzen Sie External-ID. Es gibt keinen Grund, sich überhaupt noch B2C anzusehen. Wenn Sie einen bestehenden B2C-Tenant haben, beginnen Sie jetzt mit der Planung Ihrer Migration. Sie haben bis 2030 Zeit, aber bis zur letzten Minute zu warten bedeutet, dass Sie durch eine komplexe Migration hitzen, während Sie gleichzeitig bestehende Apps am Laufen halten müssen.

Fangen Sie klein an. Wählen Sie eine Anwendung, migrieren Sie diese, testen Sie sie, lernen Sie aus dem Prozess und erledigen Sie dann den Rest. Entwicklererfahrung und Automatisierung Microsoft hat sich wirklich darauf konzentriert, External-ID für Entwickler einfach zu machen. Das ist eine riesige Veränderung gegenüber den alten, benutzerdefinierten B2C-Richtlinien und B2-Richtlinien. Kennen Sie noch diese XML-Dateien, die hunderte Zeilen lang waren und bei einer einzigen falsch gesetzten Klammer nicht mehr funktionieren? Das ist vorbei. Es gibt eine Visual Studio Code-Erweiterung namens Microsoft Entrer External-ID. Nach der Authentifizierung können Sie Ihren Tenant durch Suchen Benutzerabläufe anzeigen, die Sie als JSON-Dateien herunterladen und sogar Ihr Branding in der Vorschau sehen, alles ohne Ihren Editor zu verlassen. Sie sehen, wie Ihre Anmeldeseite aussieht, bevor Sie sie jemals veröffentlichen.

Dann gibt es noch die Microsoft Graph API. Fast jede External-ID-Ressource, Benutzerabläufe, App-Registrierung und Branding lassen sich programmatisch verwalten. Das bedeutet, dass Sie die Tenant-Einrichtungen in Ihren CICD-Pipelines mithilfe von PowerShell oder Restaufrufen automatisieren. Erstellen Sie einen neuen Tenant, konfigurieren Sie Benutzerflows, registrieren Sie Ihre App und richten Sie Branding ein Alles-Per-Skript. Wenn Sie mehrere Umgebungen verwalten, spart das enorm viel Zeit. Benutzerdefinierte Authentifizierungserweiterungen sind das, was echte Stärke ausmacht. Statt komplexer XML-Dateien erweitern Sie Authentifizierungsabläufe mit einfachen HTTP-Aufrufen an Azure Functions. Es gibt vier Ereignisse, in die Sie sich einklinken. Token-Issuance-Start erlaubt das Hinzufügen benutzerdefinierter Claims zu Tokens wie Rollen- oder Treuestufeninfos. Attribute-Collection-Start-and-Submit ermöglichen die Validierung oder Vorausfüllung von Anmeldedaten über Ihr eigenes Backend.

Und mit E-Mail-OTP-Send können Sie die Bestätigungs-E-Mails individuell anpassen. Es ist die gleiche Flexibilität wie bei B2C, aber in einem Modell, mit dem jeder Entwickler arbeiten kann. Es gibt Einschränkungen, die Sie kennen so. Es gibt noch keine Microsoft-Graph-Benachrichtigungen, daher können Sie bei einer neuen Registrierung keinen Workflow automatisch auslösen. Einige Konfigurationen müssen noch manuell im Center erfolgen, es gibt keine integrierte Seite zum Bearbeiten des Profils. Wenn Nutzer Ihre Daten aktualisieren sollen, müssen Sie diese Seite in Ihrer App bauen und die Graph API selbst aufrufen. Doch die Richtung ist klar. Microsoft möchte, dass External-ID vollständig automatisierbar ist. Das macht die Verwaltung in großem Maßstab einfacher. Jetzt wissen Sie also, Microsoft Entra External-ID ist der moderne Ersatz für Azure-ID B2C, vereint unter der Marke Entra. Die drei Anwendungsfälle, Kundenidentität, Partnerzusammenarbeit und Machine-to-Machine, decken fast jeden externen Identitätsbedarf ab.

Die entscheidende Frage ist, ob Sie Ihren Mitarbeiter-Tenant nutzen oder einen separaten externen Tenant erstellen. Für kundenorientierte Apps ist ein separater Tenant fast immer die bessere Wahl. Identität ist das Eingangstor zu Ihrer Anwendung. Wenn Sie sicher, gebrandet und einfach ist, beeinflusst dies direkt das Nutzervertrauen und das Geschäftswachstum. Ihre Hausaufgabe, gehen Sie auf entrap.microsoft.com, erstellen Sie einen externen Tenant und probieren Sie den Leitfaden für den Einstieg aus. Er führt Sie in wenigen Minuten durch die Einrichtung einer Beispiel-App. Abonnieren Sie uns für weitere einfache Erklärungen zur Microsoft-Identitätsplattform.