Documentation: Login by REST API bypasses spring-security principles

Expected Behavior

Implementing authentication via REST based API should "feel good" when implementing it according to the spring-security documentation and should not raise doubts when thinking of upcoming version upgrades or configuration changes.

Current Behavior

n/a - see context

Context

For various reasons, I am currently implementing a session-based authentication via REST API and am following the section which is an exact match for my use case.

However, as I progressed in implementing it, I am having more and more doubts and I am not sure if this is really the prefered way to go or if an authentication should rather be achieved by integrating oneself into the security filter chain.

This section clearly describes that in the case of authenticating via a REST API, one can publish the AuthenticationManager and use it accordingly.

The section even contains a note which explains that one should use the HttpSessionSecurityContextRepository to persist the SecurityContext between requests. Again, I was glad to read it because I felt that I am on the exact prefered path.

However, as I wanted to make sure that the session id changes with each login, I noticed that (of course) the filter chain settings are not applicable to my manual invocation of the AuthenticationManager. But - of course - as the name suggests the filter chain configuration, which is an essential part of spring-security - only applies to the mechanisms which are covered in the security filter chain. So I ended up calling ChangeSessionIdAuthenticationStrategy#onAuthentication manually as well.

This means that for the future, I have to keep in mind that in case something security-related gets added to the filter chain (e.g. in case a new finding is added to the OWASP list), I have to add it manually to the manual authentication which was recommended in the documentation.

It all boils down to following question:
Is this really the recommended way to provide an authentication via REST API? Or would you rather recommend to integrate it in the filter chain for my mentioned arguments?

The enhancement I would like to see (and I offer to provide a suggestion by PR) is to make this absolutely clear in the documentation - and also to mention the risk that filter chain configuration (of course) does not apply to this kind of setup.
Furthermore, the provided example for publishing the authentication manager could reference the topic of using the SecurityContextHolderStrategy

Start with the password authentication documentation section on publishing an AuthenticationManager and compare it with the session management section on SecurityContextHolderStrategy. Trace the documented REST login flow and the manually invoked ChangeSessionIdAuthenticationStrategy, then clarify whether this is recommended or should use the security filter chain. Done means the documentation explains the filter-chain limitation, session handling, and relevant configuration risks.