Nachdem wir nun einige der Sicherheitsimplikationen bei der Verwendung des OIDC-Autorisierungscode-Flows (bei öffentlichen Clients) für eine SPA betrachtet haben, folgen nun ein paar Punkte, die Sie im Auge behalten sollten, damit Ihr System optimal geschützt bleibt:
Nicht jeder IdP unterstützt den OIDC-Autorisierungscode-Flow bei öffentlichen Clients. Wenn Ihr IdP dies nicht anbietet, sind Sie auf einen IdP-spezifischen Mechanismus (z. B. ein Cookie zur Sitzungsverfolgung) angewiesen, um ohne das erneute Abfragen der Benutzeranmeldedaten ein neues Zugriffstoken zu erhalten. Dieses Vorgehen ist zwar bekannt, aber nicht durch eine Spezifikation abgedeckt.
Manche IdPs erlauben kein CORS auf dem Token-Endpunkt. Dadurch wird verhindert, dass der Browser die Antwort des Token-Endpunkts auslesen kann. Demnach wird eine SPA mit einem OIDC-Autorisierungscode-Flow und einem öffentlichen Client nicht unterstützt. Die Verwendung eines Reverse-Proxys (falls diese Option rechtlich und technisch möglich ist), kann alle CORS-Probleme mit dem Token-Endpunkt lösen. Alternativ dazu wäre die implizite Gewährung (oder der implizite Flow) der am besten geeignete Ansatz.
Szenarien mit einer verhältnismäßig kurzen Ablaufzeit für Benutzer könnten den impliziten OIDC-Flow verwenden. Wenn die gesamte Sitzungszeit des Benutzers relativ kurz bleibt und das Zugriffstoken nie abläuft, ist kein Aktualisierungstoken erforderlich. Die Verwendung des impliziten Flows ist also eine vereinfachte Option.
In manchen Fällen sind möglicherweise OAuth2-Gewährungen vorteilhafter als OIDC-Flows und umgekehrt. In meinem Beitrag dazu gehe ich ausführlich darauf ein, wann die verschiedenen OAuth2-Gewährungen und OIDC-Flows verwendet werden sollten.
Selbst wenn die SPA (oder eine andere beliebige Javascript-Anwendung, die in einem Browser läuft) eine Client-ID und ein Client-Geheimnis hat, die im Javascript-Code kodiert sind, kann dem Client-Geheimnis als Form der Authentifizierung für den Client nicht vertraut werden. Es wäre ein Kinderspiel für einen Dritten, das Client-Geheimnis zu erfahren. Dieser Ansatz ist für sich gesehen nicht unsicher, aber der IdP muss berücksichtigen, dass dies nicht mehr Sicherheit bietet, als ein öffentlicher Client ohne ein Geheimnis innerhalb seiner Sicherheitsmodelle. Wie bereits erwähnt, verhindert die redirect_uri-Whitelist, dass Anwendungen, die den Browser nicht umgehen, eine client_id wiederverwenden können.
Geben Sie das ID-Token oder Aktualisierungstoken nicht an andere Komponenten Ihrer Architektur oder an Dritte weiter. Wenn die SPA als OAuth2-Client (OIDC Relying Party) fungiert, sollte sie diese Token auf keinen Fall an eine serverseitige Komponente weitergeben. Wenn Ihre Architektur dies vorschreibt, kann die serverseitige Komponente als OAuth2-Client fungieren und als vertraulicher Client ein Client-Geheimnis sicher bewahren. In dem Fall sollte die SPA ein Cookie verwenden, damit die Sicherheitssitzung mit dem Webserver verfolgt werden kann. Die gemeinsame Nutzung des Aktualisierungstokens mit einer anderen Komponente des Systems gefährdet die Sicherheitsbeziehung zwischen dem OAuth2-Client (SPA) und dem IdP. Eine gemeinsame Nutzung eines id_token gefährdet nicht die Sicherheit zwischen dem IdP und dem Client, sondern die Sicherheit anderer Komponenten, die sich darauf verlassen (da es sich um eine Assertion handelt, die nur für diesen Client bestimmt ist). Sie möchten nicht, dass eines dieser Szenarien eintritt.
Proof Key for Code Exchange (PKCE) ist für die Verwendung mit nativen Anwendungen gedacht. Es bietet keine zusätzliche Sicherheit für eine SPA (oder Javascript-Anwendung), die in einem Browser läuft. Es kann jedoch ratsam sein, PKCE mit SPAs zu verwenden, damit ein einheitlicher Satz von OAuth2/OIDC-Verwendungsregeln beibehalten wird.
Bei der dynamischen Clientregistrierung (RFC 7591) gibt es einige Vorbehalte. Die dynamische Clientregistrierung (DCR) kann eine zusätzliche Schutzschicht für eine Instanz einer SPA-Anwendung hinzufügen, aber das dynamisch an eine Instanz der SPA ausgegebene Client-Geheimnis ist eine weitere Information, die neben dem OIDC-ID-Token, dem OAuth2-Zugriffstoken und dem OAuth2-Aktualisierungstoken geschützt werden muss. Die DCR kann das Problem mit dem Schutz dieser Werte im Browser nicht lösen. Ihr IdP sollte auch in der Lage sein, für viele OAuth2-Clients zu skalieren (einen pro Browser, Benutzer) – stellen Sie sich Ihre Anwendung in dieser Art von Szenario mit Millionen von Benutzern vor. Die DCR könnte auch einen wirksamen Mechanismus zur Erkennung von Mustern bei der Nutzung von Anwendungen bieten, der es einem IdP ermöglichen würde, die rechtmäßige Nutzung besser zu validieren, der aber von der Anwendung abstrahiert ist.
Bedenken Sie, dass als Voraussetzung für all dies der Browser und das zugrundeliegende Betriebssystem/Gerät nicht kompromittiert sein dürfen. Im Falle einer Kompromittierung wäre das meiste, was ich hier erwähnt habe, von geringer Bedeutung.