Manfred Steyer Selbstständig

Die vorhandenen Lösungen sollten aber nicht darüber hinwegtäuschen, dass eine nähere Betrachtung der jeweiligen Standards unumgänglich ist. Gerade wenn es um Detailfragen geht, müssen Architekten wissen, was möglich und was gefährlich oder gar aus Sicherheitsgründen explizit verboten ist.

Hans-Peter Grahsl Netconomy Software & Consulting GmbH

Dank bestehender Implementierungen lassen sich die populären Standards OAuth 2.0 und OpenID Connect relativ einfach zur Schaffung moderner Authentifizierungs- und Autorisierungslösungen nutzen.

Mit den Standards OAuth 2.0 und OpenID Connect lassen sich flexible Authentifizierungs- und Autorisierungslösungen auf der Basis von Security-Tokens entwickeln. Sie erlauben die Integration bestehender Identity-Lösungen wie Active Directory sowie die Nutzung zentraler Benutzerkonten für unterschiedliche Anwendungen.

Artikelserie

  • Teil 1: Authentifizierung und Autorisierung
  • Teil 2: Wiederverwendbare Pakete
  • Teil 3: Test und Build

Die wenigsten Geschäftsanwendungen kommen ohne Authentifizierung aus. Häufig müssen bestehende Identity-Lösungen wie Active Directory oder LDAP-Systeme integriert werden, um Single-Sign-on zu ermöglichen. In modernen Web-Anwendungen muss der Client auch das Recht erhalten, im Namen des angemeldeten Benutzers auf Services zuzugreifen. All diese Anforderungen lassen sich elegant mit Security-Tokens lösen. Dieser Artikel zeigt anhand eines Beispiels, wie tokenbasierte Sicherheit in einer Angular-Anwendung genutzt werden kann. Dazu kommen neben einer Angular-Anwendung ein auf ASP.NET basierendes Web-API sowie die zertifizierte Identity-Lösung Identity Server zum Einsatz. Der gesamte serverseitige Quellcode und das clientseitige Gegenstück ist auf Github abrufbar.

Security-Token mit OAuth 2.0 anfordern

Wer sich heutzutage mit tokenbasierter Sicherheit beschäftigt, kommt wohl kaum an den beiden populären Standards OAuth 2.0 und OpenID Connect vorbei. Sie beschreiben unter anderem, wie sich ein Benutzer bei einem verteilten System anmelden kann und wie ein Client das Recht erhält, im Namen des Benutzers Services zu konsumieren. Dazu kommt, dass diese Standards direkt auf HTTPS aufsetzen und sich somit wunderbar für leichtgewichtige Web-APIs eignen.

Abbildung 1 verdeutlicht die Funktionsweise von OAuth 2.0 aus der Vogelperspektive. Der Client leitet den Benutzer zur Anmeldung zu einem so genannten Authorization-Server weiter. Diese Instanz hat Zugriff auf zentrale Benutzerkonten. Hat sich der Benutzer dort angemeldet, erhält der Client einen so genannten Access-Token, das ihm im Namen des Benutzers Zugriff auf Services im Backend gibt – so genannte Resource-Server.

grahsl_steyer_oauth_1

Ein Access-Token informiert den Resource-Server unter anderem über den entsprechenden Benutzer sowie über die Rechte, die der Client im Namen des Benutzers wahrnehmen darf. Zusätzlich finden sich im Token meist auch Metadaten, wie der Aussteller, das Ausstellungsdatum oder die Gültigkeitsdauer. Diese vom Prinzip her einfache Vorgehensweise hat mehrere Vorteile:

  • Jeder Benutzer kann ein zentrales Benutzerkonto für verschiedene Clients und Services nutzen.
  • Da die Anmeldung beim Authorization-Server erfolgt, erhält der Client das Passwort nicht.
  • Die Authentifizierung ist vom Client entkoppelt und lässt sich somit in bestehende Identity-Lösungen integrieren.
  • Tokens erhöhen die Flexibilität. Beispielsweise könnte ein Service das Token an einen weiteren Service weiterreichen, um zu beweisen, dass es im Namen des Benutzers agiert. Zum Zugriff auf andere Sicherheitsdomänen kann der Service das Token auch gegen eines für diese Domäne tauschen.
  • Die Lösung kommt ohne Cookies aus. Somit kann der Client auch auf Services zugreifen, die auf anderen Servern laufen (bzw. eine andere Origin haben). Zusätzlich schränkt der Verzicht auf Cookies bestimmte Angriffe ein.

Das Format des Access-Tokens sowie die Maßnahmen, die der Resource-Server zum Validieren des Tokens unternimmt, sind von OAuth 2.0 nicht näher beschriebene Implementierungsdetails. Häufig kommen digitale Signaturen zum Einsatz, damit der Resource-Server einfach prüfen kann, ob der Token von einem vertrauenswürdigen Authorization-Server stammt. Alternativ dazu könnte der Token auch nur aus einer nicht vorhersehbaren ID bestehen, mit der der Resource-Server sich nochmals an den Authorization-Server wendet.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 4.17 - "JavaScript im Enterprise"

Alle Infos zum Heft
579778885Authentifizierung mit Security Tokens in Angular
X
- Gib Deinen Standort ein -
- or -