OIDC basiert auf OAuth 2.0. OAuth unterstützt verschiedene „Flows“, die einem Client ermöglichen an ein Access- und Refresch Token zu gelangen. Der einfachste Weg ist der Implicit Flow, bei dem dar Auhentication Server den Token direkt mit der Response an den Client sendet. Weil es einfach zu implementieren ist, wird dieser Flow von Entwicklern auch gerne eingesetzt. Dabei gerät nur zu oft die Betrachtung der Sicherheitsaspekte in den Hintergrund.

Die IETF OAuth working Group beschreibt in dem OAuth 2.0 Security Best Current Practice RFC, dass dieser Flow nicht länger eingesetzt werden sollte und auch warum:

The implicit grant (response type “token”) and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay …

In order to avoid these issues, Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response.

Der Grund ist recht einfach. Ein Angreifer kann ohne großen Aufwand das gültige Access Token aus der Respose des Servers filtern und dieses dann für andere Zugriffe, die über den gleichen IdP gesichert sind verwenden. Insbesondere, wenn wir ebenfalls auf Vereinfachungsgründen gerne so implementiert, die Gültigkeit eines Access Tokens für einen langen Zeitraum gewählt wird, kann das zu massiven Sicherheitsproblemen führen.

Die immer komplexer werdenden Einsatzszenarien, insbesondere auch im Cloud/Microservices Umfeld, erfordern zudem neue Konzepte für die Verwendung von Zugriffstoken. Hier bieten sich die Sender Constrained Token an. Entgegen der üblichen Bearer Token sind diese Token an einen Client gebunden. Dass Accesstoken kann nur unter gleichzeitiger Verifizierung des privaten Schlüssels genutzt werden. Das ist vergleichbar einer Bordingkarte beim Flugzeug, die auch an eine Person gebunden ist, im Gegensatz zu einem Gutschein für Amazon, den jeder einsetzen kann. Der Imlicit Grant Type kann an die Verwendung von Constraind Token nur schwierig angepasst werden, was aber eine Voraussetzung für die sichere Verwendung wäre.

Da der Implizit Flow urspünglich nur als Ausnahme für Browser und Java Script Apps gedacht war, ist es beim Einsatz aktuelle Browser allerdings kein Problem mehr auch andere Flows, z.B. den Authorization Code Flow, zu implementieren. Zur Zeit der Entwicklung von OAuth, um 2010, hatten im Browser ausgeführte Scripte aus Sicherheitsgründen die Einschränkung nur die same Origin ansprechen zu können. Das heißt es musste immer der gleiche Webserver antworten. Antworten eines anderen Servers auf einen http Request wurden nicht akzeptiert. Dadurch war es nicht möglich einen Authorization Server anzusprechen, wie im Authorization Code Flow vorgesehen.

Mit dieser indirekten Vergabe des Tokens werden die Möglichkeiten zum Angriff deutlich verringert. Insbesondere auch injection in http Redirects sind nicht mehr möglich. Der Implicit Flow war schon immer anfällig für Angriffe. Durch kurze Token Lebenszeiten wurde versucht das wenigstens teilweise auszugleichen.

Mit dem Cross-Origin Ressource Sharing (CORS) besteht dieses Problem bei aktuellen Browsern nicht mehr. Es gibt daher auch keinen Grund weiterhin am Implicit Flow festzuhalten. Mit CORS können Browser Anfragen auch an Sever außerhalb der ursprünglichen Origin senden, sofern der ursprüngliche Server das zulässt. Welche Server angesprochen werden dürfen, legt die Origin ebenfalls fest. In OAuth 2.0 for Browser Based Apps werden diese Best Practices noch einmal ausführlich aufgegriffen.

Wenn nun also der Implicit Flow als Option ausfällt, wird es einfacher für Entwickler. Sie brauchen sich keine Gedanken mehr zu machen welchen Flow Sie einsetzen für welchen Client. Der Code Flow ist im Allgemeinen die beste Wahl.