Welche Möglichkeiten der Web Autentication bestehen?
Sicherheit in Applikationen ist ein zentrales Thema. Unsere Erfahrung zeigt, dass die Application Security jedoch aus den unterschiedlichsten Gründen teilweise (oder sogar ganz) ausser Acht gelassen wird. In diesem Blogbeitrag zeigen wir, welche modernen Möglichkeiten einer Web App Authentication bestehen und wie diese eingesetzt werden können.
Ausgangslage, Widerstände und Probleme
Authentifizierung ist ein Thema, dass in der Planung und Entwicklung von Applikationen häufig ausser Acht gelassen wird. Viele Unternehmen setzen aus Gewohnheit auf die alte Kombination von Benutzernamen/Passwort – dies ist jedoch weder optimal noch benutzerfreundlich. Steht die Funktion einer Lösung im Zentrum, wird es bereits schwierig. Investitionen in die Erhebung von internen nicht-funktionale Anforderungen werden aufgrund von fehlendem Budget und vordergründig mangelndem Businessnutzen häufig blockiert.
Oft wird aus diesem Grund aus einem Proof-Of-Concept mit http-Protokoll und einer einfachen Benutzer-Authentifizierung ein Produkt. Ein grundsätzlich pragmatisches Vorgehen, das jedoch einige Tücken aufweist: So ist am Ende solcher Projekte meistens das «Hardening» noch offen. Zusätzlich möchte sich niemand intern exponieren, wenn die Anwendung für eine moderne Authentifizierung umgeschrieben werden muss.
Authentifizierung als Teil des Konzepts
Die Authentifizierung sollte bereits Teil des Entwicklungs-Konzepts sein und von Beginn an in das Projekt aufgenommen werden. Dies ist insbesondere vor dem Hintergrund wichtig, dass sich die Kommunikation einer modernen Authentifizierung massgeblich vom klassischen Benutzername/Passwort-Ansatz unterscheidet und eine spätere Änderung fast nicht bzw. wenn, dann nur mit grossen Anpassungen und Kosten möglich ist.
Mit einer guten Planung und der Integration der Anforderungen an die Sicherheitsmassnahmen zu Beginn eines Projektes wird der Grundstein gelegt. Ebenso sollte eine Überprüfung im Laufe Projektes stattfinden.
Moderne Authentifizierung mit OAuth
Dieser OAuth 2.0 Flow zeigt die erste Anmeldung einer Applikation (z.B. Facebook) bei einem Ressource-Server (z.B. Twitter). Die nachfolgenden Sequenzen laufen dabei beispielsweise so ab:
- Der Benutzer ruft die Applikation auf, diese stellt eine Anfrage an den Autorisierung-Server.
- Der Benutzer der App erhält die Anfrage, dass die Applikation auf den Ressource-Server zugreifen möchte. Zusätzlich wird mit einem Scope definiert, welche Rechte die Applikation haben darf. Diesen Dialog nennt man Consent. Er wird beim ersten Zugriff angezeigt (oder wenn der Scope um weitere Rechte erweitert wird).
3. Eine Login-Abfrage authentifiziert den Benutzer. Diese werden an den Autorisierung-Server gesendet. Dies ist die einzige Kommunikation, in der das effektive Passwort übermittelt wird.
4. Es wird ein einmaliger Code erstellt, welcher mittels Redirect-URL an die Applikation gesendet wird (Callback). Dieser ist nur kurze Zeit gültig. Die Redirect-URL wurde beim Einrichten von OAuth auf dem Autorisierung-Server hinterlegt.
5. Die Applikation erhält den Grant und sendet ihn an den Autorisierung-Server.
6. Als Antwort gibt es einen Access Key. Zusätzlich wird meist ein Refresh Token und weitere Daten (z.B. Benutzerdaten) mitgesendet. Der Refresh-Token kann innerhalb einer gegebenen Frist genutzt werden, um einen neuen Access/Refresh Token zu lösen. Die Tokens werden normalerweise als JWT Token verpackt. Dieser ist digital signiert und verschlüsselt.
7. Der Access Token kann nun verwendet werden, um die erlaubten (Scope) Ressourcen zu laden.
8. Die angefragten Ressourcen stehen als Antwort zur Verfügung.
Vorteile des OAuth Sicherheitsstandards
Wichtige Vorteile bei der Verwendung des modernen Sicherheitsstandards sind:
- Der Autorisierung-Server ist unabhängig von den Applikation- und Ressourcenserver. Daher kann für einen neuen Service ein bereits bestehender Login (z.B. Facebook, Google) verwendet werden.
- Die Passwörter sind nur auf dem Autorisierung-Server bekannt.
- Rechte (Scopes) legen klar fest, auf welche Ressourcen zugegriffen werden kann.
- Um Zugriffe einzuschränken oder auszuweiten, muss nicht der Benutzer geändert werden.
- Mittels einem Login kann auf mehrere Ressourcen zugegriffen werden.
Anwendung in der Praxis
Ein realer Anwendungsfall gestaltet sich die Architektur meistens komplexer als im vorangehenden theoretischen Beispiel.
In dieser Applikation wird in einer statischen Webanwendung (Static Web Site) ein Embedded Power BI Bericht gegen einen Service Principal (Service Account) von Azure AD authentifiziert. Die Authentifizierung findet gegen einen OpenID Connect Authentifizierung-Server statt. Mittels Access Token werden Ressourcen geladen und die Authentifizierung gegen das Azure AD freigegeben. Mittels AD Token wird ein Power BI Embeded Token erstellt. Die Azure Function fungiert hier als Backend, zusammen mit der statischen Webseite und Power BI als Applikation.
Im Internet finden sich unzählige Skizzen zu Authentifizierung-Flows, wobei alle unterschiedlich sind. Wichtig ist, das Konzept grundsätzlich zu verstehen. Die Visualisierung kann je nach Anforderung, Details der beteiligten Systeme und der Interpretation verschieden sein.
Die Schwierigkeit
Ihre Herausforderung – unsere Erfahrung
In vielen von uns umgesetzten Projekten durften wir unsere Expertise im Bereich der modernen Authentifizierung unter Beweis stellen. Gerne unterstützen wir auch Sie in aktuellen Herausforderungen und freuen uns, gemeinsam mit Ihnen die richtige Architektur erarbeiten zu können.
