AuthorizedClientServiceOAuth2AuthorizedClientManager usage of OAuth2AuthorizedClientService for client credentials flow

[david-sauvage]

Expected Behavior

Only save the client credentials token once in the InMemoryOAuth2AuthorizedClientService.

Current Behavior

The jwt token is saved for every principal (every user) in the InMemoryOAuth2AuthorizedClientService resulting in a memory leak.

Context

I’m developing a service which is both a resource server and a client to other http APIs.
I’m using spring boot and by extension : spring security and webclient.

I use client credentials when it comes to communicating with other APIs

My application had a memory leak issue and I found out that it was because I was using an InMemoryOAuth2AuthorizedClientService since it’s the default that comes with spring boot (documented here : https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#web.security.oauth2.client and not recommended)

The way the OAuth2AuthorizedClientService behaves in my app is that it will save for every principal (meaning every user) that comes from my controller a new jwt token retrieved with the client credentials configuration. It results in a memory leak since it saves this in memory.

Is this behavior on purpose ? What is the concept behind it that is probably out of my sight ?
The only clean alternatives I saw documented was to use a JdbcOAuth2AuthorizedClientService which is pretty heavy. Is there other alternatives ?

Thank you

[sjohnr]

@david-sauvage sorry you had trouble with the client_credentials grant and the default of storing tokens in-memory. This has been discussed before (for example, see gh-10083).

I added documentation to address this a few years ago, with gh-10120 (49f3c0c) but it appears this commit was lost when the Antora documentation updates were made around the same time. I would like to repurpose this ticket to re-add the missing documentation on this topic.

At this time, I don't believe we would look to change the default behavior. The framework is oriented towards user-based OAuth2 requests which take into account the current principal, and the missing documentation will describe the configuration you should apply for your use case.

Does that context address your issue and answer the question? If you have further questions, please feel free to open a Stack Overflow question and I'll take a look.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.