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).