Ablauf der Mehrparteien-Authentifizierung

Wenn Ihr Geschäft davon abhängt, dass Ihre individuellen Anwendungen schnell in Produktion gehen, brauchen Sie eine IAM-Plattform, die von Entwicklern und für Entwickler entwickelt wurde. Sehen wir uns an, wie Auth0 selbst anspruchsvolle Identitätsabläufe einfach implementieren kann, damit Ihre Anwendungen schneller, sicherer und mit geringerem Wartungsaufwand in Produktion gehen können.

Stellen Sie sich vor, Sie entwickeln „Lodging Picks“, eine B2B SaaS-Reiseanwendung, die Sie an Unternehmen verkaufen werden. Sie sammeln Unterkunftsangebote aus verschiedenen Quellen, darunter Hotels und RoomSMart, ein Online-Marktplatz, der AirBnB sehr ähnlich ist und Gastgeber mit Zimmern, die zu vermieten sind, mit Reisenden zusammenbringt, die auf der Suche nach kostengünstigen Unterkünften von zu Hause sind. Die Herausforderung: Buchung von RoomSMart-Immobilien über die private API¹ im Namen der Benutzer Ihrer Kunden, ohne dass Sie die Zugangsdaten für das RoomSMart-Konto besitzen.

1. Wir hätten auch AirBnB als Beispiel nehmen können, aber wir wollten nicht andeuten, dass sie tatsächlich eine solche private API zur Nutzung durch Partner anbieten. Stellen Sie sich RoomSMart wie AirBnB vor und diesen Anwendungsfall als Beispiel für ein realistisches Authentifizierungsszenario mit mehreren Parteien.

Was macht die Implementierung dieser Mehrparteien-Authentifizierung so komplex? Schauen wir uns die Anliegen der beteiligten Parteien in diesem Szenario an:

• Das Unternehmen möchte die Vorteile von Lodging Picks für sein Geschäft nutzen, muss aber den Zugriff seiner Mitarbeiter auf die Lodging Picks-Anwendung kontrollieren und möchte die Nutzung einfach gestalten. Dementsprechend möchte das Unternehmen Lodging Picks in seine SSO-Infrastruktur integrieren und muss in der Lage sein, Mitarbeiter für Lodging Picks bereitzustellen und zu deaktivieren, wenn sie das Unternehmen betreten oder verlassen.
• Die Mitarbeiterin möchte über die Anwendung Unterkünfte buchen, einschließlich RoomSMart-Zimmer, muss aber den Zugriff auf ihr RoomSMart-Konto durch Lodging Picks kontrollieren. Insbesondere darf Lodging Picks nur die Möglichkeit haben, Zimmer mit der Standard-Zahlungsmethode für ihr Konto zu buchen, nicht aber, Gastgeber zu bewerten, Nachrichten zu versenden oder Profil- oder Zahlungsinformationen zu ändern. Darüber hinaus muss sie in der Lage sein, den Zugang im Falle eines Problems zu widerrufen und ihr RoomSMart-Profil privat zu halten.
• Lodging Picks möchte seinen Unternehmenskunden einen wertvollen Service bieten, mit einer großartigen SSO-Benutzererfahrung für Unternehmensnutzer und einem neuen Kanal für RoomSMart. Aber in einer Welt, in der Sicherheitsverletzungen regelmäßig auf den Titelseiten stehen, muss Lodging Picks diese Transaktionen vermitteln und gleichzeitig den Vertrauensvorschuss für die beteiligten Parteien minimieren. Wenn nicht jeder das Gefühl hat, dass seine wertvollen Informationen sicher und unter seiner Kontrolle sind, könnten die Risiken der Nutzung dieser SaaS-Anwendung die Vorteile übersteigen.
• RoomSMart möchte gerne einen neuen B2B-Kanal zu seinen Verkäufen hinzufügen. Aber sie haben ihr Geschäft auf der Grundlage von Vertrauen aufgebaut: Gastgeber bieten Fremden/Gästen Platz in ihren Häusern an, und Gäste buchen diese Zimmer auf der Grundlage von Beschreibungen auf der Website sowie von Bewertungen und Kommentaren anderer Gäste. Sowohl Gastgeber als auch Gäste speichern sensible Daten in dem Dienst, und RoomSMart muss die Privatsphäre wahren und Gesetze und Vorschriften einhalten und gleichzeitig ein sehr einfaches Benutzererlebnis bieten. Dementsprechend erlauben sie wahrscheinlich anderen Anwendungen nicht, Anmeldedaten zu speichern, sie kontrollieren den API-Zugang streng, sie geben den Eigentümern sensibler Daten die volle Kontrolle und sie behalten die Möglichkeit, ihre Nutzungsbedingungen durchzusetzen.

Wenn dies kompliziert erscheint: Das ist es auch! Aber es ist auch typisch für moderne Web- und mobile Anwendungen, die durch die Zusammenstellung von Diensten entstehen, die in der „API-Wirtschaft“ aus unabhängigen Quellen verfügbar sind. Authentifizierung und Autorisierung sind die entscheidenden Werkzeuge, die regeln, wie sich solche Dienste in einer von Natur aus nicht vertrauenswürdigen Umgebung gegenseitig vertrauen können.

Heutzutage gibt es keine Lösung, die anspruchsvolle Authentifizierungsabläufe mit mehreren Parteien wie diese standardmäßig abwickelt. Tools mit eingebauten und einfachen Authentifizierungsabläufen können dies nicht leisten. Um Lodging Picks zu implementieren, müssten Sie unter Umständen eine benutzerdefinierte IAM-Lösung zu beträchtlichen Kosten selbst entwickeln, spezialisierte Mitarbeiter einstellen und eine teure, kontinuierliche Wartung einrichten. Was Sie wirklich brauchen, ist eine API-gesteuerte Identitätsplattform, die für die Flexibilität von Entwicklern optimiert ist und die Anwendungen vereinfacht, bei denen die Identität über Unternehmensgrenzen hinweg gilt. Sie brauchen Auth0.

Was muss hier geschehen? Der Benutzer – ein Mitarbeiter Ihres Kunden – meldet sich bei Lodging Picks mit seinen föderierten Unternehmensanmeldeinformationen an. Auth0 vereinfacht diesen Prozess und macht es Ihnen leicht, SSO für Ihre Kunden zu implementieren. Sobald ein Benutzer authentifiziert ist, müssen Sie einen Onboarding-Workflow ausführen, der es Lodging Picks ermöglicht, die RoomSMart-API zu verwenden, um RoomSMart-Unterkünfte im Namen des Benutzers anzuzeigen und zu buchen.

Warum bitten Sie den Benutzer nicht einfach, sich bei Lodging Picks mit seinen Unternehmens- und RoomSMart-Zugangsdaten anzumelden und dann die Konten zu verknüpfen, damit der Benutzer beide Konten für den Zugriff auf Lodging Picks verwenden kann? Dieser Ansatz würde nicht funktionieren: Der Benutzer könnte mit seinen RoomSMart-Anmeldedaten auf Lodging Picks zugreifen, auch wenn er kein Mitarbeiter des Unternehmens mehr ist. Der Zugriff auf die Anwendung Lodging Picks darf nur über das Unternehmenskonto des Mitarbeiters erfolgen, und zwar über SSO.

Was wäre, wenn Sie den Benutzer bitten würden, seinen RoomSMart-Namen und sein Passwort in der Anwendung Lodging Picks zu speichern? Das könnte funktionieren, verstößt aber gegen die bewährten Verfahren. Es ist sowohl für RoomSMart als auch für den Mitarbeiter viel unsicherer, könnte Lodging Picks zu einem attraktiveren Ziel für Hacker machen und könnte daher von RoomSMart untersagt werden.

Wie können Sie also nur den Zugriff auf RoomSMart erhalten, den Sie im Namen des Benutzers benötigen, ohne dessen RoomSMart-Anmeldedaten zu besitzen, und sich nur mit dem Unternehmenskonto des Benutzers authentifizieren?

Abbildung 1: Auth0 Regel-Pipeline

Auth0 enthält eine leistungsstarke Funktion – Pipeline-Regeln für die Authentifizierung –, mit der Sie Code hinzufügen können, der nach jeder Authentifizierung ausgeführt wird, um eine benutzerdefinierte Verarbeitung hinzuzufügen. Die Regeln können beliebigen Code enthalten, der Transaktionen protokolliert, mit Analyseplattformen verknüpft, zusätzliche Authentifizierungen wie die Multi-Faktor-Authentifizierung initiiert oder zusätzliche APIs aufruft, um auf zusätzliche Informationen zuzugreifen oder zusätzliche Arbeiten durchzuführen. Regeln können Benutzer auf externe Websites oder Dienste umleiten und nach der Rückkehr das Ergebnis weiterverarbeiten. Diese Möglichkeit, beliebigen Code in die Authentifizierungs-Pipeline einzufügen, ist eine der leistungsfähigsten Funktionen von Auth0.

Mit nur ein paar Dutzend Zeilen Javascript können Sie selbst einen komplexen Authentifizierungs-Workflow mit mehreren Parteien und mehreren Protokollen wie den für Lodging Picks implementieren. Wir implementieren also unseren Workflow als Regel (der Prototyp des Javascript-Codes befindet sich in Anhang A, am Ende dieses Anwendungsfalls). Wenn die Regel feststellt, dass Auth0 noch kein Refresh-Token für RoomSMart gespeichert hat, z. B. wenn sich ein Benutzer zum ersten Mal bei Lodging Picks anmeldet, unterbricht sie die Authentifizierungsverarbeitung des Benutzers und leitet ihn auf die API-Berechtigungsseite von RoomSMart weiter. Der Benutzer erteilt Auth0 dann die Erlaubnis, im Namen von Lodging Picks ein benutzerspezifisches API-Refresh-Token zu erwerben und sicher im Profil des Benutzers zu speichern, das wiederum zum Erwerb eines Zugriffstoken mit eingeschränkten Zugriffsrechten und kurzem Ablaufdatum verwendet werden kann. Lodging Picks kann die API von Auth0 aufrufen, umuser.app_metadata_encrypted_roomsmart_refresh_token abzurufen und nach dem Erwerb des Zugangstoken RoomSMart-Abfragen und -Buchungen im Namen des Benutzers durchzuführen. Der Benutzer behält die volle Kontrolle und kann diesen Zugang jederzeit widerrufen, indem er sein RoomSMart-Konto besucht. RoomSMart kann auch das Refresh- oder Zugriffstoken widerrufen. Eine andere Regel könnte automatisch das Refresh-Token verwenden, um ein neues Zugriffstoken zu erhalten, bevor das alte abläuft.

Abbildung 2: Beispiel Workflow für die Mehrparteien-Authentifizierung

Mit den Umleitungsregeln von Auth0 können Sie die Authentifizierungs-Pipeline unterbrechen, um einen beliebigen Dienst aufzurufen. Sie sind nicht auf den Code beschränkt, den Sie in Ihrer Anwendung geschrieben haben. Mit dieser leistungsstarken Funktion können Sie das Web-API-Ökosystem nutzen oder benutzerdefinierte Integrationen in Unternehmensanwendungen erstellen.

In der umfassenden Dokumentation und den Beispielen von Auth0 erfahren Sie mehr darüber, wie Sie Umleitungsregeln implementieren können, und in Anhang A finden Sie einen Prototyp einer Regel, die diesen speziellen Anwendungsfall implementiert.

Beliebige Codeausführung bedeutet, dass Sie die Flexibilität haben, komplexe Authentifizierungs- und Autorisierungs-Workflows zusammenzustellen, ohne eine benutzerdefinierte IAM-Lösung erstellen und pflegen zu müssen. Und das alles mit einfachen Hooks und der umfassenden Front-End- und Back-End-Plattformunterstützung von Auth0, um die Entwicklung zu beschleunigen.

Wenn es an der Zeit ist, Ihre nativen IOS- und Android-Anwendungen zu implementieren, können Ihre Entwickler diesen produktiven Identitäts-Workflow ohne zusätzlichen Aufwand nutzen – mobile Apps verwenden die gleichen Auth0-APIs. Ganz einfach!

Moderne Web- und Mobilanwendungen bestehen aus Diensten, die über APIs aufgerufen werden, die von unabhängigen Unternehmen und Einrichtungen gehostet werden. Die Sicherheit in diesem API-Ökosystem hängt von der Authentifizierung ab: Die Dienste müssen wissen, dass die Aufrufe ihrer API für den Zugriff auf personenbezogene Daten und sensible Aktionen legitim und von ihren Kontoinhabern genehmigt sind. Da die Anwendungen immer komplexer werden, lassen sich die Nutzungsmuster und Zugriffsanforderungen dieser unabhängigen APIs nicht im Voraus vorhersagen und in starre Designmuster einbauen. Die API-Ökonomie erfordert codegesteuerte Flexibilität bei der Handhabung von Authentifizierungsabläufen. Die Regeln der Authentifizierungs-Pipeline von Auth0 machen es Entwicklern leicht, solche benutzerdefinierten Abläufe zu erstellen, und erleichtern es den Endbenutzern, sich in diesen Szenarien zurechtzufinden, in denen eine Mehrparteien-Authentifizierung erforderlich ist.

Auth0 verfügt über ein weiteres einzigartiges Merkmal – sein viel gelobtes Customer Success Team. Hilfe ist nur einen Slack-Chat oder eine E-Mail entfernt, damit Sie alle Hürden schnell überwinden und Ihre geschäftskritischen Anwendungen in Produktion bringen können.

Für weitere Informationen wenden Sie sich an das Auth0-Vertriebsteam, oder probieren Sie es einfach aus! Der volle Funktionsumfang der Auth0-Plattform ist für Entwicklungszwecke immer kostenlos. Erstellen Sie noch heute Ihr kostenloses Konto unter auth0.com und entdecken Sie den Unterschied für Entwickler.

Hier ist ein Beispielcode, der die in diesem Anwendungsfall beschriebene Regel implementiert. Sie erhält einen Autorisierungscode über den RoomSMart-Zustimmungsfluss und tauscht diesen Code dann gegen ein Refresh-Token aus. Die Regel verschlüsselt dann dieses Refresh-Token und speichert es als Anwendungsmetadaten im Profil des Benutzers.

function(user, context, callback) {
    // If we already have the user's refresh token, don't ask for consent again.
    user.user_metadata = user.user_metadata || {};
    if (user.app_metadata.encrypted_roomsmart_refresh_token) {
        return callback(null, user, context);
    }

    var CLIENT_ID = '123456';
    var CLIENT_SECRET = 'ABCDEFG';

    // Umleitung zur RoomSMart-Webanwendung, um um Zustimmung zu bitten.
    if (context.protocol !== 'redirect-callback') {
        var REDIRECT_TO = 'https://roomsmart.com';
        var REDIRECT_PATH = '/oauth2/authorize?client_id=' + CLIENT_ID +
            '&redirect_uri=http://lodgingpicks.auth0.com/continue&response_type=code' +
            '&scope=offline_access%20read_account';

        context.redirect = {
            url: REDIRECT_TO + REDIRECT_PATH
        };

        return callback(null, user, context);
    }
    // Wir werden wieder zurückgeleitet.
    else {

        // No consent given.
        if (context.request.query.error) {
            return callback(new UnauthorizedError(context.request.query.error_description));
        }

        // Zustimmung erteilt, Austausch des Autorisierungscodes gegen Token
        var token_request = {
            body: 'grant_type=authorization_code' +
                '&client_id=' + CLIENT_ID +
                '&client_secret=' + CLIENT_SECRET +
                '&redirect_uri=http://lodgingpicks.auth0.com/continue' +
                '&code=' + context.request.query.code
        };
        request.post('https://roomsmart.com/oauth2/token', token_request, function(err, res, body) {
            if (err) {
                return callback(err);
            }

            var token_response = JSON.parse(body);
            if (!token_response.refresh_token) {
                return callback(new UnauthorizedError('Refresh token is missing'));
            }

            // Verschlüsseln des Refresh-Token.
            user.app_metadata.encrypted_roomsmart_refresh_token = encrypt(token_response.refresh_token);

            // Speichern im Profil des Benutzers.
            auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
                .then(function() {

                    // Continue the authentication transaction.
                    callback(null, user, context);
                })
                .catch(function(err) {
                    callback(err);
                });
        });
    }

    // Hilfsmittel zur Verschlüsselung sensibler Daten.
    function encrypt(data) {
        var iv = new Buffer(configuration.ENCRYPT_IV);
        var decodeKey = crypto.createHash('sha256')
            .update(configuration.ENCRYPT_PASSWORD, 'utf-8').digest();
        var cipher = crypto.createCipheriv('aes-256-cbc', decodeKey, iv);
        return cipher.update(JSON.stringify(data || {}), 'utf8', 'base64') + cipher.final('base64');
    }
}