So optimieren Sie die Authentifizierungserfahrung für Ihre Kunden-Apps

Steve Dillon
Senior Solutions Architect

---

Wenn Sie bei der Entwicklung Ihrer Web- und Online-Apps ein Team für Kundenerfahrung (CX) hinzugezogen haben, wird oft davon ausgegangen, dass Sie ein sehr spezifisches und markendefiniertes Erlebnis liefern. Selbst, wenn Sie kein separates CX-Team beschäftigen, ist es unabdingbar für Ihr Geschäft, eine konsistente und nahtlose Kundenerfahrung bereitstellen zu können.

Damit die Authentifizierungserfahrung in dieser mobilen Welt wie erwartet (oder sogar gefordert) gewährleistet werden kann, müssen zunächst einige Hürden überwunden werden. Sogar moderne Identitätsprotokolle wie OAuth haben Grenzen. Beim OAuth-Protokoll werden die Kunden zur Authentifizierung oft zwangsläufig von Ihrer Anwendung weg und wieder zurückgeleitet. Dies macht sich besonders bei mobilen Anwendungen bemerkbar, bei denen die Benutzerfreundlichkeit von verschiedensten Netzwerkbedingungen und dem unterschiedlichen Präsentationsstil der Anwendung und des Identitätsanbieters gestört werden kann.
 

Es gibt nicht immer eine klar definierte Lösung für dieses Dilemma. Oft kommt es darauf an, das richtige Gleichgewicht zwischen Kosten und CX zu finden, um die Anforderungen Ihres Unternehmens zu erfüllen. Wenn beispielsweise die Kosten der maßgebliche Faktor sind, kann eine Standard-Benutzeroberfläche ausreichen. Auf diese Weise können Sie, realistisch gesehen, 70-80% der gewünschten Kundenerfahrung für 20% des Preises einer benutzerdefinierten Lösung bieten. Möglicherweise ist dies ausreichend für Ihre Anforderungen.

Viele Unternehmen haben in der CX jedoch einen Wettbewerbsfaktor erkannt. Wenn die Kundenwahrnehmung an erster Stelle steht, ist nur eine hundertprozentige digitale Erfahrung gut genug.

Warum Sie mehr als nur Basic OAuth für die Kundenauthentifizierung brauchen

Das OAuth-Protokoll hat sich zu einem unschätzbaren Werkzeug im Identity Toolkit entwickelt. Wenn Sie es als Methode einsetzen, um Benutzerdaten zwischen zwei Computern auszutauschen, wird es diese Funktion bestens erfüllen. Beispielsweise ermöglicht OAuth Nutzern, Slack auf ihre Google-Dienste zugreifen zu lassen, sodass:
 

1. Sie ihre Google-Anmeldedaten nicht an Slack weitergeben müssen.
2. Sie die Kontrolle darüber behalten, was Slack in ihrem Namen sehen und tun darf.
   
   

Wie Sie sehen, wurde OAuth als Autorisierungsprotokoll konzipiert. Es hat mit der Authentifizierung nichts zu tun, sondern geht davon aus, dass diese bereits erfolgt ist. Das wirkt sich in zweierlei Hinsicht auf das Authentifizierungserlebnis aus:
 

1. OAuth bietet nicht wirklich die Möglichkeit, Benutzer zu authentifizieren.
2. OAuth schiebt im Grunde Benutzer zwischen Identitätsanbietern und Anwendungen, die Identitätsdaten verwerten, hin und her.
   
   

Wenn Sie sich daher bei der Bereitstellung Ihrer Authentifizierung auf OAuth stützen, gehen Sie folgende Kompromisse ein:
 

1. Die Authentifizierung wird dann eher vom Identitätsanbieter gesteuert als von den Anwendungsentwicklern, was häufig einen höheren organisatorischen Aufwand bedeutet.
2. Die Umleitung selbst erfolgt auch nicht besonders reibungs- und nahtlos.
3. Da Anwendungs- und Anmeldeerfahrungen unabhängig voneinander verwaltet werden, kann diese Gestaltung als unzusammenhängend wahrgenommen werden.
   
   

Obwohl diese Kompromisse manchem weniger relevant erscheinen mögen, so ist die Kundenerfahrung (CX) doch von immenser Bedeutung für jeden, der mit kundenorientierten Anwendungen arbeitet. Sie benötigen eine bessere Lösung, als eine, die „gerade gut genug“ ist, um die reibungslosen und konsistenten Erfahrungen zu liefern, die Ihre Kunden erwarten.

Binden Sie die Authentifizierungs-API in PingFederate ein.
 

Überblick über die PingFederate Authentifizierungs-API

Mithilfe der Authentifizierungs-API kann Ihr Anwendungs-Team überlegene Kundenerfahrungen bieten. Die Authentifizierung wird direkt in die Anwendungen eingebettet, sodass Sie die CX direkt von Ihren Applikationen aus steuern können. Mit der Authentifizierungs-API vermeiden Sie auf diese Weise umständliche Umleitungen und können selbst bei instabilen Verbindungen über das mobile Internet eine reibungslose Erfahrung garantieren. Sie können außerdem das Erscheinungsbild Ihrer Anwendungen engmaschig kontrollieren und gleichzeitig die Kompatibilität mit OAuth-und OIDC-Standards aufrechterhalten.

Damit kommen wir zu der Frage, wie die Authentifizierungs-API aufgebaut ist. Sie können sich die Anfragen an Ihre Authentifizierungs-API als einen Ablauf in drei Schritten vorstellen:
 

Ich stelle mir das gern als Authentifizierungs-Sandwich mit OAuth-Sauerteig vor. Sie beginnen mit einer standardmäßigen OAuth-Initiation, durchlaufen die für die Authentifizierung erforderlichen Schritte und machen dann (nach der Authentifizierung) dort weiter, wo Sie im OAuth-Flow aufgehört haben.

Es muss darauf hingewiesen werden, dass die oben dargestellten beispielhaften Endpunkte für ein einfaches Authentifizierungs-Szenario ausreichen. In der Umsetzung jedoch wird Ihre Anwendung mit verschiedenen Situationen konfrontiert, wie beispielsweise die Anforderung einer MFA, gesperrte Konten, vergessene Passwörter und so weiter.

Es ist auch wichtig zu erwähnen, dass die Authentifizierungs-API mit Kundendaten agiert, einschließlich Passwörtern und Einmalpasswörtern, und sich daher nur für den Einsatz innerhalb Ihres Unternehmens eignet. Es ist für Dritte nicht sicher, Ihre Authentifizierungs-API zu verwenden.

Die Auswahl Ihres Bereitstellungsmodus

Die PingFederate Authentication API unterstützt zwei Bereitstellungsmodi. Welchen Sie einsetzen hängt von Ihrem Anwendungsfall ab, aber sie schließen sich nicht gegenseitig aus. Es ist plausibel, den ersten Modus (den Ablauf ohne Umleitung) für mobile Anwendungen zu verwenden und gleichzeitig den zweiten Modus zu nutzen, um ein zentrales Authentifizierungsportal aufzubauen, das single sign-on (SSO) für Webclients ermöglicht.
 

Eingebettete Anwendung (ohne Umleitung)

Dieser Bereitstellungsmodus ist dann nützlich, wenn Sie die Anmeldeerfahrung innerhalb Ihrer eigenen mobilen App verwalten möchten, ohne dafür die Nutzer an einen externen Identitätsanbieter (IdP) umzuleiten. Er eignet sich ideal für die Steuerung des Anmeldungserlebnisses einer einzelnen Anwendung. Darüber hinaus funktioniert er wesentlich besser, wenn die mobilen Nutzer nur einen schwachen Empfang haben, da die API sehr wenige Nutzdaten benötigt.

Wenn Sie jedoch erweiterte Workflow-Anforderungen haben oder einen zentralisierten Dienst erstellen möchten (z. B. weil Sie SSO und nicht nur die Authentifizierung für eine einzelne Anwendung benötigen), sollten Sie den nächsten Bereitstellungsmodus in Betracht ziehen.
 

Authentifizierungsportal

PingFederate liefert ein erstaunliches Potenzial für Erweiterbarkeit. Mit den Velocity-Templates können Sie das Erscheinungsbild mithilfe von HTML, CSS und Javascript praktisch nach Belieben anpassen. Die Verfügbarkeit von Konfigurationsoptionen wie Datenspeicher, lokale Identitätsprofile, Passwortvalidatoren und Authentifizierungsrichtlinien ermöglichen einen äußerst flexibel gestaltbaren Authenifizierungsablauf.

In manchen Situationen ist jedoch ein alternativer Ansatz zu empfehlen. Beispielsweise:

• Wenn Sie eine Abstraktionsschicht für Identitäten in Erwägung ziehen, um eine Anbieterbindung zu vermeiden.
• Bei umfangreichen Geschäftsanforderungen und Systemintegrationen macht es mehr Sinn, die Anmeldung als separate Einheit zu verwalten.
• Wenn Ihr Unternehmen über eine ausgereifte DevOps-Praxis mit erprobten Tools, Prozessen und Technologien verfügt, dann ist es sinnvoller, diese zu nutzen, anstatt einen Bereich mit einer neuen Technologie aufzubauen.
   

Ein benutzerdefiniertes Authentifizierungsportal kann ebenfalls eine Lösung für diese Szenarien darstellen. In diesem Bereitstellungsmodus werden die Anwendungen weiterhin als Clients in PingFederate konfiguriert, allerdings erfolgt die Authentifizierung hier nicht mithilfe von vorkonfigurierten Templates, sondern die Nutzer werden zum Authentifizierungsportal weitergeleitet. Das Authentifizierungsportal liefert das gewünschte Erscheinungsbild und den Ablauf, während es die Nutzer über die Authentifizierungs-API bei PingFederate authentifiziert.

Da dies in der Weise des oben erwähnten Authentifizierungs-Sandwich geschieht, sind alle Abläufe kompatibel mit OAuth/OIDC und profitieren von PingFederate-Funktionen wie SSO und Multifaktor-Authentifizierung (MFA).

Wollen Sie von jetzt an mit hervorragenden Authentifizierungs-Erlebnissen punkten?

Nachdem Sie nun die Arbeitsweise der Authentifizierungs-API kennen, können Sie im nächsten Schritt hervorragende Authentifizierungs-Erlebnisse bereitstellen. Informationen darüber, wie Sie mit der Authentifizierungs-API in PingFederate einen großen Schritt voran kommen, erfahren Sie in dieser Schritt-für-Schritt-Anleitung.