Native Authentifizierung (Vorschau)
Mit der nativen Authentifizierung von Microsoft Entra haben Sie vollständige Kontrolle über das Design der Anmeldeumgebung für Ihre mobilen Anwendungen. Im Gegensatz zu browserbasierten Lösungen können Sie mit der nativen Authentifizierung visuell ansprechende, pixelgenaue Authentifizierungsbildschirme erstellen, die sich nahtlos in die App-Benutzeroberfläche einfügen. Mit diesem Ansatz können Sie die Benutzeroberfläche u. a. mit Designelementen, Logoplatzierung und Layout vollständig anpassen, um ein einheitliches Branding sicherzustellen.
Der standardmäßige Anmeldeprozess für mobile Apps, der auf browserdelegierter Authentifizierung basiert, führt häufig zu einem störenden Übergang während der Authentifizierung. Benutzer werden zur Authentifizierung zunächst vorübergehend zu einem Systembrowser weitergeleitet und dann nach Abschluss des Anmeldeprozesses zurück zur App geleitet.
Die browserdelegierte Authentifizierung hat zwar gewisse Vorteile, etwa reduzierte Angriffsvektoren und Unterstützung für einmaliges Anmelden (Single Sign-On, SSO), bietet aber nur eingeschränkte Optionen zur Anpassung der Benutzeroberfläche und eine geringe Benutzerfreundlichkeit.
Verfügbare Authentifizierungsmethoden
Derzeit unterstützt die native Authentifizierung den lokalen Kontoidentitätsanbieter für zwei Authentifizierungsmethoden:
- Anmeldung mit per Email gesendetem Einmal-Passcode (OTP)
- Anmeldung mit E-Mail- und Kennwort mit Unterstützung für die Self-Service-Kennwortzurücksetzung (SSPR)
Die native Authentifizierung unterstützt noch keine Verbundidentitätsanbieter wie Social-Media- oder Unternehmensidentitäten.
Anwendungsszenarien für die native Authentifizierung
Bei der Implementierung der Authentifizierung für mobile Apps mit External ID haben Sie zwei Möglichkeiten:
- Von Microsoft gehostete browserdelegierte Authentifizierung.
- Vollständig benutzerdefinierte, SDK-basierte native Authentifizierung.
Der gewählte Ansatz hängt von den spezifischen Anforderungen Ihrer App ab. Obwohl jede App über eigene Authentifizierungsanforderungen verfügt, gibt es einige allgemeine Überlegungen, die Sie berücksichtigen sollten. Es ist egal, ob Sie die native oder browserdelegierte Authentifizierung auswählen, Microsoft Entra External ID unterstützt beide.
In der folgenden Tabelle werden die beiden Authentifizierungsmethoden verglichen, um eine Entscheidungshilfe für die richtige Option für Ihre App zu bieten.
| Browserdelegierte Authentifizierung | Native Authentifizierung | |
|---|---|---|
| Authentifizierungsvorgang für Benutzer | Benutzer werden für die Authentifizierung zunächst zu einem Systembrowser oder eingebetteten Browser weitergeleitet und dann nach Abschluss des Anmeldeprozesses zurück zur App geleitet. Dies wird empfohlen, wenn sich die Umleitung nicht negativ auf die Endbenutzererfahrung auswirkt. | Benutzer werden durch eine umfassende, native erste Registrierung und Anmeldung für mobile Geräte geführt, ohne die App verlassen zu müssen. |
| Anpassung | Verwaltete Branding- und Anpassungsoptionen sind als sofort einsatzbereite Funktion verfügbar. | Dieser API-zentrierte Ansatz bietet ein hohes Maß an Anpassung, umfassende Flexibilität beim Entwurf und die Möglichkeit, maßgeschneiderte Interaktionen und Abläufe zu erstellen. |
| Anwendbarkeit | Er ist geeignet für Mitarbeiter-, B2B- und B2C-Apps und kann für native Apps, Single-Page-Webanwendung und Web-Apps verwendet werden. | Bei mobilen Erstanbieter-Apps für Kunden, wenn der Autorisierungsserver und die App von derselben Entität betrieben werden und der Benutzer beide als dieselbe Entität wahrnimmt. |
| Aufwand für Liveschaltung | Niedrig. Kann direkt verwendet werden. | Hoch. Der Entwickler erstellt, besitzt und verwaltet die Authentifizierung. |
| Wartungsaufwand | Niedrig. | Hoch. Für jedes Feature, das Microsoft veröffentlicht, müssen Sie das SDK aktualisieren, um es zu verwenden. |
| Security | Die sicherste Option. | Die Sicherheitsverantwortung wird mit Entwicklern geteilt, und bewährte Methoden müssen befolgt werden. Anfällig für Phishingangriffe. |
| Unterstützte Sprachen und Frameworks |
|
|
Verfügbarkeit von Funktionen
Die folgende Tabelle zeigt die Verfügbarkeit von Features für die native und browserdelegierte Authentifizierung.
| Browserdelegierte Authentifizierung | Native Authentifizierung | |
|---|---|---|
| Registrieren und Anmelden per E-Mail und Einmal-Passcode (OTP) | ✔️ | ✔️ |
| Registrierung und Anmeldung mit E-Mail und Kennwort | ✔️ | ✔️ |
| Self-Service-Kennwortzurücksetzung (SSPR) | ✔️ | ✔️ |
| Anmeldung mit sozialem Netzwerk als Identitätsanbieter | ✔️ | ❌ |
| Multi-Faktor-Authentifizierung mit Einmal-Passcode (OTP) per E-Mail | ✔️ | ❌ |
| Einmaliges Anmelden (Single Sign-On, SSO) | ✔️ | ❌ |
Verwenden der nativen Authentifizierung
Sie können Apps, welche die native Authentifizierung nutzen, mithilfe unserer nativen Authentifizierungs-APIs oder des MSAL (Microsoft Authentication Library, Microsoft-Authentifizierungsbibliothek)-SDKs für Android und iOS erstellen. Wir empfehlen, möglichst MSAL zum Hinzufügen der nativen Authentifizierung zu Ihren Apps zu verwenden.
Weitere Informationen zu Beispielen für die native Authentifizierung und Tutorials finden Sie in der folgenden Tabelle:
| Sprache/ Plattform |
Codebeispiel-Anleitung | Anleitung zum Erstellen und Integrieren |
|---|---|---|
| Android (Kotlin) | • Anmelden von Benutzern | • Anmelden von Benutzern |
| iOS (Swift) | • Anmelden von Benutzern | • Anmelden von Benutzern |
Wenn Sie planen, eine mobile App in einem Framework zu erstellen, das derzeit von MSAL nicht unterstützt wird, können Sie unsere Authentifizierungs-API verwenden. Weitere Informationen finden Sie in diesem API-Referenzartikel.