OIDC basiert auf OAuth 2.0. OAuth unterstützt verschiedene „Flows“, die es einem Client ermöglichen, an ein Access- und Refresh Token zu gelangen. Der einfachste Weg ist der Implicit Flow, bei dem der Authentication 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, warum dieser Flow nicht länger eingesetzt werden sollte:

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 Response des Servers filtern und dieses dann für andere Zugriffe, die über den gleichen IdP gesichert sind, verwenden. Insbesondere, wenn wir ebenfalls aus Vereinfachungsgründen gerne so implementieren, dass die Gültigkeit eines Access Tokens für einen langen Zeitraum gewählt wird, kann dies zu massiven Sicherheitsproblemen führen.

Die immer komplexer werdenden Einsatzszenarien, insbesondere auch in 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 mit einer Boardingkarte beim Flugzeug, die auch an eine Person gebunden ist, im Gegensatz zu einem Gutschein für Amazon, den jeder einsetzen kann. Der Implicit 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 aktueller 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, dies 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 für welchen Client einsetzen. Der Code Flow ist im Allgemeinen die beste Wahl.