© Stmool/Shutterstock.com
API-Authentifizierung mit Azure Active Directory - Teil 2

Einrichtung von Azure AD B2C


JSON Web Tokens (JWT) nach dem OAuth-Standard sind derzeit erste Wahl, wenn es darum geht, den Zugriff auf Web-APIs abzusichern. Die Unterstützung dieser Technologie ist in fast allen aktuellen Sprachen und Frameworks vorzufinden und dank guter Bibliotheksunterstützung inzwischen mit überschaubarem Aufwand in eigene Projekte zu integrieren.

Die notwendige Infrastruktur für die eigentliche Authentifizierung von Benutzern stellen mittlerweile etliche Dienstleister aus der Cloud bereit, auch die Tokens stellen sie aus. Für Windows-Entwickler lohnt sich immer auch der Blick auf das Gebotene aus dem Hause Microsoft Azure. Im ersten Teil dieser Artikelserie [1] haben wir die Tools der „Microsoft Identity Platform“ in unserem Azure-Testmandanten benutzt und uns die Hintergrundtechnik für das Ausstellen von ID- und Access-Tokens und die Authentifizierung von sowohl lokalen Benutzern als auch bestehenden Benutzerkonten unseres (Firmen-)Active Directory in Azure eingerichtet. Dazu haben wir ein neues sogenanntes B2C-Verzeichnis angelegt, das die lokalen Benutzer aufnimmt, und es mit unserem Hauptmandanten gekoppelt, der die Rolle des bestehenden Firmen-AAD übernommen hat. Der Zusammenhang zwischen den beiden Mandanten (Tenants) und den dort erstellten Objekten ist in Abbildung 1 grafisch dargestellt.

Dieser Teil befasst sich mit der Clientseite und zeigt am Beispiel, wie mit einer Webanwendung die abgesicherten Endpunkte unseres API konsumiert werden können. Die Authentifizierung der Benutzer der Webanwendung erledigt unser in Teil 1 angelegter Benutzerflow. Um das Clientbeispiel funktionsfähig nachzubauen, benötigen wir neben Visual Studio auch die eingerichtete Azure-AD-B2C-Umgebung sowie das Beispiel-API mit der Wettervorhersage aus dem ersten Teil.

schmitt_api_authentifizierung_teil2_1.tif_fmt1.jpgAbb. 1: Azure-Mandanten der Beispielinfrastruktur

Die Clientapplikation registrieren

Die Wettervorhersage, die unser Beispiel-API ausliefert, soll in einer Clientapplikation abgerufen und dargestellt werden. Weil der Endpunkt /weatherforecast zum Abrufen des Wetterberichts abgesichert ist, muss die anfragende Clientapplikation ein gültiges Zugriffstoken (Access Token) in der Anfrage präsentieren. Wir hatten am Ende des ersten Teils schon festgestellt, dass es sinnvoll ist, APIs und konsumierende Applikationen als getrennte Anwendungen in Azure AAD zu registrieren. Denn zum einen könnte es mehrere Applikationen geben, die ein- und dasselbe API nutzen müssen, zum anderen wird eine Applikation in typischen Microservices-Szenarien in der Regel mehrere verschiedene APIs nutzen. Eine enge Kopplung des APIs an eine Applikation ist also nicht zielführend. Deshalb wird die Clientanwendung als neue App-Registrierung in Azure eingetragen und bekommt somit auch eine eigene neue client id.

Melden wir uns nun in unserem Azure-Konto unter https://portal.azure.com an und wechseln in das B2C-Verzeichnis, das wir im ersten Teil angelegt haben – in meinen Screenshots war das der „Testmandant für B2C“. Die Funktion zum Wechseln des Verzeichnisses findet sich im Browserfenster oben rechts unter dem Symbol für das Benutzerkonto. Hier muss gegebenenfalls der Reiter Alle Verzeichnisse gewählt werden, wenn die Auswahl das gewünschte Verzeichnis nicht anzeigt. Anschließend rufen wir über die Suchleiste am oberen Rand der Seite die App-Registrierungen auf und klicken auf Neue Registrierung. Diese Testanwendung nennen wir „Applikation1“ und wählen bei Unterstützte Kontotypen die dritte Option (Microsoft hat in diesem Dialog leider nur die Hälfte übersetzt). Die anderen Einstellungen belassen wir auf den Standardvorgaben. Die Erstellung des Eintrags erfolgt per Klick auf den Button Registrieren (Abb. 2). Anschließend wird eine Übersichtsseite mit der Registrierung dargestellt. Lassen wir diese zunächst in unserem Browser geöffnet, denn wir kehren gleich dorthin zurück, wenn unser Beispielcode startklar ist.

schmitt_api_authentifizierung_teil2_2.tif_fmt1.jpgAbb. 2: Registrieren der Clientanwendung in Azure

Eine einfache Beispielanwendung

Um zu zeigen, wie der Zugriff auf das abgesicherte API erfolgt, werden wir eine ganz einfache und schnörkellose Webapplikation verwenden, die mit ein wenig HTML und JavaScript auskommt und so den Blick auf das Wesentliche nicht versperrt. Diese Applikation soll dem Nutzer die Anmeldung über die eingerichtete Azure AD B2C ermöglichen, sodann die E-Mail-Adresse des eingeloggten Benutzers anzeigen und im zweiten Schritt den Abruf der Wettervorhersage über unser API durchführen. Um Ihnen Tipparbeit zu ersparen, habe ich den Quellcode unter [2] bereitgestellt. Laden Sie sich diesen herunter oder klonen Sie das Repository und fügen Sie das Verzeichnis am besten der Projektmappe des Visual-Studio-Projekts mit dem Beispiel-API WebAPI1 hinzu (rechte Maustaste auf die Projektmappe, dann Hinzufügen | Vorhandene Website…). Damit gleich beide Projekte starten, sollten noch beide als Startprojekte festgelegt werden. Das erfolgt via Rechtsklick auf die Projektmappe, dann Startprojekte festlegen… und beide Projekte auswählen. Selbstverständlich können API und Beispielanwendung auch in getrennten Projektmappen organisiert werden.

Im Beispielcode (Listing 1) müssen noch die Konfigurationswerte auf die jeweils eigene Testumgebung angepasst werden. Dazu werden in der Datei main.js die Zeilen 12 bis 15 entsprechend abgeändert:

  • clientId: Hier wird die Client-ID Ihrer gerade durchgeführten App-Registrierung für die Applikation1 eingetragen.

  • authority: Im URL wird anstelle des Mandantenbezeichners alexandersb2c der Bezeichner des eigenen B2C-Mandanten eingesetzt (zu finden auf der Übersichtsseite der Ressource Azure AD B2C im Azure Portal).

  • knownAuthorities: Hier muss ebenfalls der Mandantenbezeichner durch den eigenen ersetzt werden.

  • re...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang