ich möchte unsere Sicherheitslage verbessern, und dazu gehört, dass wir geheime Anmeldeinformationen vermeiden müssen, wann immer es möglich ist.
Leider benötigte das OIDC-Plugin ein geheimes Client-Anmeldeinformationsgeheimnis, um den /userinfo-Endpunkt zu erreichen, und ich konnte mein Forum mit aktivierter Funktion nicht einrichten.
Glücklicherweise ist die OIDC-Spezifikation so definiert, dass keine geheimen Token verwendet werden müssen.
Wenn wir uns an den id_token-Flow halten, sendet uns der IdP alle Informationen, die wir benötigen, um einen Benutzer zu authentifizieren, ohne dass wir uns erneut an den IdP wenden müssen.
Dies ist sicher, da die Umleitung im IdP konfiguriert ist und wir uns keine Sorgen machen müssen, dass das Bearer-Token an das falsche Ziel weitergeleitet wird.
Ich habe bereits einen Patch für das OIDC-Plugin erstellt, um den id_token-Flow zu unterstützen, und hier eine Pull-Anfrage eingereicht:
Die PR ist noch nicht ganz vollständig, da noch Unit-Tests fehlen, aber sie ist so gut wie fertig und ich habe bestätigt, dass sie mit Azure AD (Entra ID) ordnungsgemäß funktioniert.
Zur Referenz finden Sie hier die Dokumentation für das OIDC-Plugin:
Ich glaube, dass Sie hier den OpenID Connect "Implicit Flow" beschreiben, der ohne serverseitige Kommunikation auskommt und daher kein gemeinsames Geheimnis benötigt. Stattdessen werden alle Informationen über die HTTP-Weiterleitungen übertragen, und das ID-Token wird kryptografisch mit den öffentlichen Schlüsseln aus dem Discovery Document verifiziert.
Das ist in Ordnung, und ich denke, es ist eine gültige Funktionsanfrage. Aber es ist ein ganz anderes System als unser aktuelles Plugin, das den Authorization Code Flow verwendet. Dieser Flow verwendet serverseitige Kommunikation mit einem gemeinsamen Geheimnis, und daher ist keine kryptografische Verifizierung des id_token erforderlich. Dies ist in mancher Hinsicht einfacher, in anderer jedoch komplexer.
Wichtig: Wir können die Standardimplementierung im Plugin nicht einfach ändern. Websites, die den Authorization-Code-Flow verwenden, müssen diesen weiterhin nutzen. Soweit ich weiß, unterstützen viele Identitätsanbieter den Implicit Flow gar nicht.
Daher sehe ich hier zwei Wege:
Wir fügen Unterstützung für den „Implicit Flow“ im OIDC-Plugin hinzu, machen ihn aber zu einer Opt-in-Funktion. Ich glaube nicht, dass wir einen PR akzeptieren werden, der das openid-connect-Gem als Abhängigkeit von Discourse Core einführt. Daher müsste es innerhalb unserer aktuellen Strategie implementiert werden.
Das discourse-lti (Learning Tools Integration) Plugin könnte eine nützliche Inspirationsquelle sein, da das LTI-Protokoll auf dem OIDC Implicit Flow basiert. Die Logik zum Dekodieren des id_token finden Sie hier.
oder alternativ
Sie erstellen den Implicit Flow als völlig neues Plugin. In diesem Fall können Sie bei der Implementierung tun, was Sie möchten (müssen es aber auch selbst pflegen).
Es ist auch erwähnenswert, dass der OIDC „Implicit Flow“ die Angriffsfläche für CSRF-Angriffe und Token-Exposition erhöht:
Ich denke, es kann immer noch für einige Situationen sinnvoll sein. Aber es scheint, dass der Authorization Code Flow (Discourse’s Standard) mit PKCE (optional in Discourse) der am meisten empfohlene Weg ist, OIDC zu verwenden.
Ich denke, es kann in manchen Situationen immer noch Sinn machen. Aber es scheint, dass der Authorization Code Flow (Discourse’s Standard) mit PKCE (optional in Discourse) der am meisten empfohlene Weg ist, OIDC zu verwenden.
Das ist sehr interessant – ich habe PKCE bis jetzt nicht vollständig verstanden. Basierend auf meiner Lektüre der Auth0-Dokumentation scheint dieser Flow (in bestimmten Konfigurationen) die Vorteile des Implicit Flows (kein Client Secret) ohne dessen Nachteile zu haben.
Ist das vielleicht etwas, das stattdessen getan werden kann? Es sieht so aus, als wäre es so einfach wie das Entfernen des Client Secret-Parameters aus dem /token-Endpunkt.
Und letztendlich ist meine Hauptsorge einfach die Eliminierung der Anforderung eines Client Secrets
diff --git a/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb b/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb
index 410a88f46dc..e74ee360aae 100644
--- a/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb
+++ b/plugins/discourse-openid-connect/lib/omniauth_open_id_connect.rb
@@ -73,6 +73,11 @@ module OmniAuth
)
options[:client_options][:auth_scheme] = :request_body
end
+
+ # Wenn wir PKCE verwenden UND kein client_secret vorhanden ist, verwenden Sie das request_body auth_scheme.
+ if options[:pkce] && options[:client_secret].empty?
+ options[:client_options][:auth_scheme] = :request_body
+ end
end
def request_phase
Die Redirect-URI ist im Azure-Control-Panel wie folgt konfiguriert:
