Ungelöst OAuth2-Logout im Drittsystem: Wie kann auch die ChurchTools-Session beendet werden?

[alex-muehlbauer]

Ausgangssituation

Die Integration von ChurchTools als OAuth2-Provider in eine Spring-Boot-Anwendung ist insofern gelungen, als dass der OAuth2-Login funktioniert, der OAuth2-Logout jedoch nicht wie erwartet:

• Beim Login wird der Browser zu ChurchTools weitergeleitet.
• Nach erfolgreicher Anmeldung erhält meine Anwendung den Authorization Code und tauscht ihn gegen einen Access Token.
• Gleichzeitig besteht anschließend im Browser eine gültige ChurchTools-Session.
• Öffne ich ChurchTools in einem zweiten Tab desselben Browser-Fensters, bin ich dort ebenfalls angemeldet.
• Beim Logout beendet meine Anwendung ihre lokale Spring-Session und entfernt den gespeicherten OAuth2 Authorized Client.
• Fehler Die ChurchTools-Session im Browser bleibt jedoch bestehen.
• Fehlverhalten Ein erneuter OAuth2-Login meldet den Nutzer deshalb ohne erneute Eingabe seiner Zugangsdaten sofort wieder an.

Erprobte Ansätze

• Das Entfernen des lokalen OAuth2 Authorized Client beendet erwartungsgemäß nur die Sitzung meiner Anwendung.
• POST /api/logout mit dem OAuth2-Access-Token als Bearer liefert 401 Unauthorized.
• POST /api/logout mit dem Header Authorization: Login <OAuth2-Access-Token> liefert ebenfalls 401 Unauthorized. Offenbar ist ein ChurchTools-Login-Token nicht mit einem OAuth2-Access-Token gleichzusetzen.
• Der Aufruf HTTP GET https://<instanz>.church.tools/?q=logout invalidiert die ChurchTools-Session erfolgreich, wenn er als Top-Level-Navigation im Browser erfolgt. Danach landet der Nutzer allerdings auf der ChurchTools-Loginseite und nicht wieder in der aufrufenden Anwendung.
• Derselbe Aufruf über ein verstecktes iframe ist keine belastbare Lösung. Der Request wird zwar ausgeführt, der ChurchTools-Session-Cookie kann im Third-Party-Kontext aber durch SameSite- beziehungsweise Browser-Schutzmechanismen unterdrückt werden.
• Ein separates Browserfenster funktioniert technisch, führt jedoch zu einer schlechten und nicht akzeptablen Benutzerführung.
• Der Aufruf über Swagger funktioniert, weil Swagger unter der ChurchTools-Domain läuft und deshalb den vorhandenen ChurchTools-Session-Cookie mitsenden kann.

Gewünschtes Verhalten

Nach dem Logout in der Drittanwendung soll folgender Ablauf möglich sein:

1. Die lokale Sitzung der Anwendung wird beendet.
2. Die ChurchTools-Session wird über einen offiziell unterstützten Logout-Flow invalidiert.
3. Der Browser wird anschließend zu einer registrierten URL der Anwendung zurückgeleitet.
4. Der Nutzer sieht wieder die Login-Seite der aufrufenden Anwendung.

Vorschlag

Hilfreich wäre ein OAuth2-/OIDC-kompatibler Front-Channel-Logout-Endpunkt, beispielsweise mit:

• einer registrierten post_logout_redirect_uri,
• optionalem state zum sicheren Fortsetzen des Ablaufs,
• Unterstützung für Public Clients ohne Client Secret,
• eindeutiger Dokumentation, welcher Token beziehungsweise welche Browser-Session beendet wird,
• Validierung der Rücksprung-URL gegen die registrierten Redirect-URIs.

Sinngemäß beispielsweise: HTTP GET /oauth2/logout?post_logout_redirect_uri=https://example.org/login&state=.... Die ChurchTools-Session könnte dabei über den Browser-Cookie identifiziert und anschließend zur erlaubten Rücksprung-URL weitergeleitet werden. Ein Access Token sollte dabei nicht über die URL übertragen werden.

Fragen

• Welcher Request-Flow ist für den Logout eines über ChurchTools angemeldeten OAuth2-Nutzers vorgesehen?
• Gibt es bereits einen dokumentierten Front-Channel-Logout mit Rücksprung-URL?
• Kann /​?q=logout eine validierte Rücksprung-URL erhalten?
• Gibt es alternativ einen Token-Revocation- oder Backchannel-Logout-Endpunkt, der auch die zugehörige ChurchTools-Browser-Session beendet?
• Wie soll dieser Flow bei einem Public Client ohne Client Secret umgesetzt werden?