-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth2AuthorizationRequest should expire #5145
Comments
@rwinch I've been thinking about assigning this as a first-timer issue. However, as I looked into this further, I'm not sure if we really need to implement this. The current and only implementation for |
Can you remind me why we want to expire it? Where is the configured limit coming from? |
@rwinch You proposed this change to me way back and I logged the issue as I thought it was a good idea at the time as well.
If the user triggers the Authorization Code flow OR the
This would be part of the feature if implemented. I'm guessing we would have a setter in the implementation(s) of |
Thanks for the reminder. It's probably not a huge deal, but I'd like to leave this open. It is technically a memory leak and sessions can be kept around quite a long time. |
@rwinch @jgrandja We recently observed this issues which caused an increase in per call overhead in our gateway, due to near 4k of As I did not want to invalidate existing sessions a companion map was added to the session holding a configurable amount of If you like I could provide a PR for this change? Imho I would prefer a limit based solution over a time based one as a possible attacker could just create a lot of |
@AndreasKl I believe this solution should have both time-limit and size-limit. The size-limit will prevent resource exhaustion and the time-limit will ensure resources are not wasted. For the time-limit feature, I believe an With the time-limit feature alone, I wonder if the size-limit would be needed? |
@jgrandja Ok, started to build a solution for the time based expiration (the prototype can be found in this draft PR) Now I have a few questions..
|
We should definitely add a skew setting and
I would prefer a component that can be used between webflux and servlet. This would be ideal of course but we'll need to ensure we're not blocking on the reactive impl.
I still feel this is a cross-cutting concern so I would prefer to externalize the expiry logic and have it scheduled. I'd rather not embed the logic in |
… default Add setAllowMultipleAuthorizationRequests allowing applications to revert to the previous functionality should they need to do so. Closes spring-projectsgh-5145 Intentionally regresses spring-projectsgh-5110
Closing in favor of gh-9649 |
… default Add setAllowMultipleAuthorizationRequests allowing applications to revert to the previous functionality should they need to do so. Closes spring-projectsgh-5145 Intentionally regresses spring-projectsgh-5110
We should ensure the
OAuth2AuthorizationRequest
expires after the configured time limit.The text was updated successfully, but these errors were encountered: