Steve Riesenberg

Thanks for reaching out @kschlesselmann! I'm sorry to hear about your concurrency issues with multiple access token requests, but I'm glad that you have been able to develop a solution...

@kschlesselmann thanks for the sample. It's hard to talk about things concretely without that and I should have asked for one before going very far, but thanks for providing it...

> The plot I provided in the original issue shows login requests of our production system. I see, thanks. Can you clarify what you mean by "login requests"? I think...

@benba thanks for reaching out! This is a fairly nuanced topic, particularly because (as you pointed out) the specification doesn't paint a perfectly clear picture. A reading of the core...

Apologies for the noise on this issue, I mixed up this issue # with gh-11298. By way of an update, my goal is to partially address this issue via work...

Thanks for the update @marbon87. I think that makes sense for the workaround.

Hi everyone. I have merged gh-15337 which includes new implementations of `OAuth2AccessTokenResponseClient` for servlet applications, which are implemented much more consistently with the reactive counterparts. The goal is to make...

Hi @marbon87, As mentioned in [this comment](https://github.com/spring-projects/spring-security/issues/14811#issuecomment-2201271420), we cannot adjust the behavior in the `DefaultRefreshTokenTokenResponseClient` as it would not be backwards compatible. However, the new implementation `RestClientRefreshTokenTokenResponseClient` behaves the same...

Thanks for the feedback @marbon87. As mentioned in [this comment](https://github.com/spring-projects/spring-security/issues/14811#issuecomment-2201271420), directly addressing this issue would break passivity. Instead, users on the servlet stack can opt-in to `RestClient`-based implementations that are...

Related #10309 (and possibly #8882)