Authentifizierung in die App bringen

Die Rolle von APIs bei Identity as a Service

| Autor / Redakteur: Pascal Jacober * / Stephan Augsten

Login-Mechanismen selbst zu bauen, ist nicht immer die beste Lösung, über APIs lassen sich bei Bedarf auch externe Dienste einbinden.
Login-Mechanismen selbst zu bauen, ist nicht immer die beste Lösung, über APIs lassen sich bei Bedarf auch externe Dienste einbinden. (© peterschreiber.media - stock.adobe.com)

Identitätsprüfung muss sein, aber kein Developer wird sich wirklich um deren Implementierung reißen. Per API lässt sich Identity as a Service, kurz IDaaS, allerdings recht einfach in eigene Lösungen integrieren.

Im Vordergrund der Software-Akzeptanz steht immer die einfache Nutzbarkeit – denn jede Applikation, die von Kunden genutzt werden soll, wird daran gemessen. Ein unbequemes Login, eine umständliche Registrierung oder die Notwendigkeit eines Passwort-Resets kann den Kunden kosten.

Selbst so einfache Dinge wie Passwort-Richtlinien können unglaublich frustrierend werden. Eine einzige ungewohnte Einstellung und bewährte Passwörter funktionieren nicht. Der Account muss neu aufgesetzt werden – mit Login-Daten, die man noch leichter vergisst. Wer jetzt den Dienst nicht absolut zwingend benötigt, gibt auf.

Es ist also extrem wichtig, den Prozess für Identitätsfunktionen wie Logins einfach zu gestalten. Das selbst zu bauen, ist sicherlich nicht die beste Lösung. Ein Entwickler muss dafür maßgeschneiderte Login- und Registrierungsoberflächen bauen, den Ablauf eines Passwort-Resets entwerfen – und das alles, ohne den Launch der Applikation zu verzögern.

Ein übersehenes Detail kann bereits für den Anwender frustrierend sein. Oder, noch schlimmer, zum Einfallstor für Hacker werden. Was liegt also näher, als bestehende Identity-Dienste zu nutzen, um Fallstricke zu vermeiden und sich Entwicklungsstunden zu sparen?

APIs machen IDaaS

API-basierte Identity-as-a-Service (IDaaS) Lösungen ermöglichen es Entwicklern, Identitätsdienste einfach einzusetzen. Für Sicherheit und bewährte Abläufe sorgen dann Spezialisten seitens des Anbieters – Verschlüsselung für Passwörter und Anwenderdaten, Abläufe bei Registrierung und Account Recovery, ein sicheres User-Repository und andere Funktionen mit Identitätsbezug.

Eine weitere Möglichkeit ist es, Identity-Dienste auszulagern. Rund um Identitäten gibt es unendlich viele Details, Erfahrungen und auch Richtlinien, die in diese Dienste einfließen sollten – das selbst zu machen, ist viel problematischer und darüber hinaus auch sehr zeitaufwändig. Aber nicht jede Identity-Lösung bietet genau das, was man jeweils braucht – und damit drohen kurzfristige, ungeplante Anpassungen. Geringe Nutzerfreundlichkeit gefährdet Kundenbeziehungen; sind die APIs nicht robust, wird es schwierig, den Dienst zum Laufen zu bekommen.

Was muss eine IDaaS-Lösung können?

1. Gibt es APIs, anpassbare UIs und einen Self-Service für Entwickler?

Wenn nicht, wird es hart für Entwickler. Nur mit Self-Service können sie die IDaaS selbst mir ihrer App verbinden, ohne auf andre IT-Ressourcen zugreifen zu müssen. Ist die App einmal verbunden, müssen die APIs einfach einzusetzen und intuitiv sein sowie robuste Funktionalitäten bieten. In manchen Situationen braucht man keine Anpassungen für die Identity-APIs. Dann kann man auch vorgefertigte UIs einfach auf das eigene Markenbild anpassen, und das war’s. Kurz, APIs und UIs, die fertige Identity-Dienste wie Registrierung, Authentifizierung, die Abläufe hinter dem Passwort-Reset oder ähnliches nutzen, sparen Zeit, Ressourcen und Nerven.

2. Gibt es ein Social-Login sowie Präferenz- und Profil-Monitoring?

Kunden sind beim Umgang mit Marken wählerisch geworden. Kleine Fehler, wie keine Login-Option über Facebook oder ihre Lieblings Social-Media-Plattform, und sie nutzen die App nicht mehr. Kunden wollen und müssen aus Datenschutzgründen ihre Account-Daten und Präferenzen selbst verwalten. Ihr Team kann also diese Präferenzen nutzen, um die App auf die Kundenbedürfnisse anzupassen. Mit einer passenden IDaaS-Lösung wird es erleichtert, diese Möglichkeiten einzubetten, ohne den Entwicklungsprozess zu verlangsamen.

3. Muss man noch ein eigenes User-Repository bauen?

Eine Anwender-Tabelle erstellen, Passwörter verschlüsseln und zugleich auf Skalierbarkeit und Sicherheit zu achten, ist ein aufwändiger und riskanter Job. Ein Versehen kann die Applikation zum Einfallstor für Hacker & Co. machen und Millionen kosten. Es ist wesentlicher vorteilhafter für Entwickler, einfach ein bereits abgesichertes User-Repository zum Laufen zu bringen, statt eine eigene User Datenbank aufzubauen und in Eigenregie schützen zu müssen. Ist das Cloud User-Repository einmal aufgesetzt, heißt es nur noch, Zugriff, Update und Modifizierung über eine Entwickler-freundliche API vorzunehmen.

4. Wie steht es um MFA für Anwender?

Die beliebtesten Apps verwenden heute Multi-Faktor Authentifizierung (MFA) – das wird von Konsumenten und Sicherheitsexperten gleichermaßen erwartet. Aber MFA ist nicht gleich MFA. So sind SMS und Mail keine sichere MFA. Diese Annahme hat beispielweise Reddit während eines Angriffs teuer bezahlen müssen.

Eine erheblich sicherere Variante für die Anwender ist es, MFA direkt in die Applikation einzubetten. Es ist auch bequemer, zum Beispiel einen Fingerabdruck auf dem Smartphone zu hinterlassen, als in einem vielstufigen Prozess eine separate App oder Mail zu öffnen, ein einmaliges Passwort zu kopieren und im Browser einzufügen.

Es mag zwar ideal sein, MFA über Push-Benachrichtigungen anzubieten, das Vorgehen taugt aber nicht für alle Anwender. Diese sollten ihre bevorzugte Methode wählen können – auch wenn manche doch wieder SMS oder Mail bevorzugen. Eine IDaaS-Lösung sollte also unterschiedliche MFA-Features bieten, etwa die Möglichkeit, Transaktionen mit hohem Wert abzusegnen – und Details darüber zu liefern, was ein Kunde in der SMS, dem Mail oder der Push-Benachrichtigung absegnet.

5. Kann man damit in einem einzigen Account unterschiedliche Umgebungen hosten?

Oft sollen die Applikationen in unterschiedlichen Umgebungen laufen – Umgebungen für Development, Staging und Produktion oder auch unterschiedliche Sets von Umgebungen für die verschiedenen Anwendungen. Eine IDaaS-Lösung muss genau das ermöglichen – für die Entwickler, aber auch für die IT.

Identity in eine Applikation einzubauen, hat Auswirkungen, die weit in die Zukunft reiche können. Spätere Initiativen zur Vereinheitlichung von Identity-Profilen kommen beispielsweise. Oder Maßnahmen im Rahmen der digitalen Transformation können maßgeblich werden – etwa wenn Anwendungen in eine zentralisierte Identitätsinfrastruktur integriert werden.

Diese Integration kann über die IDaaS-Lösung leichter werden – also ohne erneute Überarbeitung und Implementierung. Der Vorteil dabei: Präferenzen und Daten zu Personen, die von anderen Applikationen im Unternehmen gesammelt werden, können in jeder App für eine bessere User-Experience genutzt werden.

Es lohnt, schon früh spezifische Anforderungen der IT zu beachten. So kann die IDaaS Lösung als Authentifizierungs-Autorität benötigt werden und muss damit in der Lage sein, eine beliebige Anzahl an Single Sign-on (SSO) Anwendungsfällen im ganzen Unternehmen zu verwalten. Oder die Identitätslösung muss in einer hybriden IT Umgebung bestehen und die einheitliche Profile auf On-premises Apps ausweiten.

Pascal Jacober
Pascal Jacober (Bild: Ping Identity)

Denkt man schon früh an diese Kriterien, wird die Integration von Identity-Features in eine App erheblich einfacher. Die Alternative ist bitter: Sicherheitslücken, schlechtere User-Experience, eine mühsame Implementierung von Identity-Features oder eine spätere Nachbesserung in den Apps.

* Pascal Jacober ist Sales Manager DACH bei Ping Identity.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45635115 / APIs)