Access-Token wird nicht refreshed bei Zugriff auf API-Gateway, sondern jedes Mal erneut beim Backend-Zugriff

[rowe42]

Dieses Issue ist ein Merker, da es sich entweder um einen Bug in Spring-Security-Oauth2-Boot handelt oder um eine Fehlkonfiguration unsererseits. Das eigentliche Problem habe ich in diesem Issue beschrieben, in der Hoffnung, dass jemand aus der Spring Community uns hilft: https://github.com/spring-projects/spring-security-oauth2-boot/issues/5

@xdoo @dragonfly28 @Baumfrosch @ejcsid

[rowe42]

Ich habe mir jetzt einen halben Tag Zeit genommen und einen abgestrippten, minimalen Showcase des Problems erstellt. Ein Spring Programmierer hatte mich in Issue https://github.com/spring-projects/spring-security-oauth2-boot/issues/5 darum gebeten. Wollte ich euch nicht vorenthalten, findet sich inklusive Anleitung hier: https://github.com/rowe42/oauth2_showcase

[rowe42]

Im o.g. Showcase habe ich noch eine Lösung ergänzt, wie sich das Access Token per MVCInterceptor updaten lässt.

Allerdings bringt das in unserem Fall leider nicht viel:

• Von Zuul bediente Zugriffe werden standardmäßig nicht per MVCInterceptor intercepted, da Zuul sein eigenes Servlet hat (kann man aber forcieren: https://stackoverflow.com/questions/37553487/interceptor-not-getting-called-when-zuul-routes-configured-in-gateway)
• Bei jedem Backend-Zugriff wird in Klasse OAuth2TokenRelayFilter sichergestellt, dass das ein valides Access Token verwendet wird. Dieses wird entgegen dem, was ich zunächst dachte NICHT jedes Mal neu geholt.
• Im Frontend Security-Context hängt dann zwar noch immer das abgelaufene Token. Das lässt sich aber nicht über einen MVCInterceptor ändern (denn auch der Zugriff auf statische Frontend-Dateien (html) wird standardmäßig nicht über MVCInterceptor abgefangen).

Ich habe mal in Branch ZuulHandler im API-Gateway gezeigt, wie der SecurityInterceptor arbeiten würde. Ich baue das aber nicht in den Master-Branch ein, weil es keinen Vorteil bringt gegenüber dem, was OAuth2TokenRelayFilter macht (mit Ausnahme davon, dass man dann das aktuelle Token im SecurityContext hätte, aber das ist für uns nicht wirklich relevant).

Ich schließe dieses Issue. Wir bleiben beim Status Quo wie Zuul das macht - das ist für unsere Zwecke akzeptabel, wenn auch nicht ideal / perfekt.